output : Que se passe-t-il avec cette transaction "Saisie d'adresse nulle" ?
- Le destinataire d'une transaction spécifie les conditions de dépense dans un script de sortie.
- L'évaluation des scripts d'entrée et de sortie est essentielle pour valider une transaction.
- L'utilisation de scripts de sortie non standards peut nécessiter plus de manipulation et ne garantit pas plus de confidentialité.
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.
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 :
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 :
Le script d'entrée dans la première entrée de 54fa…814f est :
Le script équivaut essentiellement à une version obscurcie d'une sortie P2PK, comme le montre l'évaluation de l'exécution du script :
Pile actuelle (à gauche en bas) : SIG
Pile : SIG -1
Pile : SIG -1 -1
Pile : SIG -1 -1 0
b) de la pile et renvoie un 1 à la pile car a (-1) est inférieur à b (0).
Pile : SIG -1 1
Pile : SIG -1
élément supérieur de la pile par sa valeur absolue
Pile : SIG 1
Pile : SIG 1 1
Pile : SIG 1 1 16
Pile : SIG 1
élément supérieur de la pile et le place sur la pile alternative.
Pile : SIG, Altstack : 1
Pile : SIG PUBKEY, Altstack : 1
Pile :, Altstack : 1
Pile : 1, Altstack :
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. 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é.
