Output - Que se passe-t-il avec cette transaction "Saisie d'adresse nulle" ?

Lorsqu'un destinataire demande à recevoir de l'argent, il précise les conditions dans lesquelles il souhaite pouvoir dépenser les fonds dans un script de sortie. Plus tard, lorsque le destinataire souhaite dépenser ses fonds, il doit fournir un script d'entrée qui satisfait le script de sortie de la sortie qu'il dépense. Lors de la validation des transactions, le script d'entrée est évalué en premier, puis la pile résultante est utilisée comme point de départ pour évaluer le script de sortie.

Par exemple avec P2PKH, le script d'entrée contient une signature et une clé publique, le script de sortie contient OP_DUP OP_HASH160 pubkeyhash OP_EQUALVERIFY OP_CHECKSIG.

Lors de l'évaluation, le script d'entrée pousse d'abord la signature puis la clé publique sur la pile. La pile est ensuite transmise au script de sortie qui :

duplique la clé publique

remplace la première des deux copies de la clé publique par un hachage de la clé publique

pousse le pubkeyhash vers la pile

Vérifie que le pubkeyhash poussé depuis le script de sortie et le pubkeyhash haché depuis la pubkey dans l'entrée sont égaux

Vérifie que la clé publique et la signature restantes constituent une signature valide de la transaction

Il existe un certain nombre de scripts de sortie standardisés pour une utilisation fréquente. Certains d'entre eux couvrent des cas d'utilisation à signature unique, mais il existe également plusieurs types de sortie standard pour les scripts complexes. Les adresses constituent un raccourci pratique pour communiquer les scripts de sortie du destinataire à l'expéditeur pour les types de scripts de sortie standard. Même avant l'introduction de P2SH, un récepteur pouvait définir des conditions arbitraires en écrivant le script de sortie correspondant à l'aide des opcodes définis dans Bitcoin Script. Ces scripts nus sont rares, car leur contenu arbitraire ne se prête pas à une norme d'adresse. L'UX est horrible : au lieu d'une adresse avec une somme de contrôle, le destinataire et l'expéditeur doivent échanger le script réel, et l'expéditeur doit créer une transaction brute spécifiant manuellement le script de sortie. (P2SH a été introduit pour améliorer l'UX en définissant vos propres conditions de dépenses tout en permettant une norme d'adresse.)

La transaction que vous examinez contient un tel script simple : au lieu de suivre l'un des schémas de sortie standard, le récepteur a défini son propre script de sortie et l'a satisfait en conséquence dans l'entrée suivante.

Le script de sortie spécifié dans la sortie a601…0e0c:0 de la transaction précédente est :

OP_DUP OP_0 OP_LESSTHAN OP_VERIFY OP_ABS OP_PUSHNUM_1 OP_PUSHNUM_16 OP_WITHIN OP_TOALTSTACK OP_PUSHBYTES_33 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 OP_CHECK SIGVERIFY OP_FROMALTSTACK

Le script d'entrée dans la première entrée de 54fa…814f est :

OP_PUSHBYTES_72 3045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e9105 5938750815b6d8a675902e01OP_PUSHNUM_NEG1

Le script équivaut essentiellement à une version obscurcie d'une sortie P2PK, comme le montre l'évaluation de l'exécution du script :

Le script d'entrée place une signature sur la pile.
Pile actuelle (à gauche en bas) : SIG

Le chiffre -1 est poussé sur la pile
Pile : SIG -1

La pile est passée à la validation du script de sortie

Le chiffre -1 est dupliqué
Pile : SIG -1 -1

Un 0 est poussé sur la pile
Pile : SIG -1 -1 0

OP_LESSTHAN consomme deux éléments (a, b) de la pile et renvoie un 1 à la pile car a (-1) est inférieur à b (0).
Pile : SIG -1 1

OP_VERIFY consomme le 1 en haut de la pile et réussit
Pile : SIG -1

OP_ABS remplace l'élément supérieur de la pile par sa valeur absolue
Pile : SIG 1

Un 1 est poussé vers la pile
Pile : SIG 1 1

Un 16 est poussé vers la pile
Pile : SIG 1 1 16

OP_WITHIN consomme trois valeurs (x min max) et renvoie un 1 car x est supérieur ou égal au minimum et inférieur au maximum
Pile : SIG 1

OP_TOALTSTACK supprime l'élément supérieur de la pile et le place sur la pile alternative.
Pile : SIG, Altstack : 1

Une clé publique est poussée sur la pile :
Pile : SIG PUBKEY, Altstack : 1

OP_CHECKSIGVERIFY consomme la signature et la clé publique et vérifie que la signature est valide dans le contexte de la transaction et de la clé publique.
Pile :, Altstack : 1

OP_FROMALTSTACK supprime la valeur supérieure de la pile alt et la place sur la pile :
Pile : 1, Altstack :

Le script réussit car il se termine par une seule valeur véridique 1 sur la pile

Ces transactions peuvent interrompre certains explorateurs de blocs dans le sens où certains explorateurs de blocs peuvent uniquement prendre en charge les scripts standard et n'afficheront pas correctement les sorties nues. Il me semble que les explorateurs de blocs modernes n'en souffrent plus :
par exemple, mempool.space affiche le script de sortie dans la transaction précédente…

… et la transaction de dépenses se passe très bien.

Dans le cas où « briser les explorateurs de blocs » était compris comme un avantage en matière de confidentialité, cette transaction n’est pas plus privée. Dans les transactions Bitcoin, les fonds ne sont pas dépensés à partir d'adresses : les adresses précisent simplement les conditions dans lesquelles les fonds peuvent être dépensés, mais chaque entrée doit spécifier exactement le résultat de la transaction qu'elle dépense. La transaction précédente a601…0e0c a créé une seule sortie a601…0e0c:0 avec le script de sortie nu mentionné qui pourrait être dépensé par le propriétaire de ce script, et la première entrée de 54fa…814f a explicitement dépensé ce a601…0e0c:0, pour créer une autre sortie de transaction 54fa…814f:0 qui peut être dépensée par le récepteur contrôlant l'adresse 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB. Autrement dit, chaque UTXO est identifiable de manière unique et le graphique des transactions est une information publique. L’absence d’adresse n’a aucun avantage en matière de confidentialité.