Scripts standards : P2PKH et P2SH

Curiosité

1. Pourquoi Bitcoin verrouille-t-il les pièces sur un hash plutôt que sur la clé elle-même ?
2. Comment un script à quatre lignes peut-il vérifier à la fois la propriété et l’autorisation en une seule exécution ?
3. Qu’est-ce qui a fait du P2PKH le format d’adresse par défaut pendant plus de huit ans de l’histoire du réseau ?

Explorer

Partie IPay-to-public-key-hash (P2PKH)

1. Le bloc de genèse ne contenait que des sorties Pay-to-Public-Key (P2PK). Ces scripts plaçaient la clé publique complète (en 2009, une clé non compressée de 65 octets) directement dans la sortie, visible avant toute dépense, et rendaient les sorties volumineuses. Le P2PKH, également présent dans le logiciel original de 2009 et utilisé pour les paiements ordinaires vers des adresses, stocke à la place un hash de 20 octets, ce qui cache la clé jusqu’à ce que les pièces soient dépensées.
2. Le script de verrouillage est `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG`. L’exécution commence avec les données de celui qui dépense sur la pile : la signature, puis la clé publique au sommet. Le moteur duplique la clé, la hache avec RIPEMD-160(SHA256(clé)) et compare le résultat au hash stocké. S’ils correspondent, `OP_EQUALVERIFY` réussit ; sinon, l’exécution s’arrête immédiatement.
3. Une fois la vérification du hash réussie, `OP_CHECKSIG` vérifie la signature ECDSA au regard de la clé publique révélée et des données de la transaction. Ce double mécanisme garantit que seul le détenteur de la clé privée correspondante peut déverrouiller les fonds. Le script de sortie fait 25 octets au total, une structure compacte qui est devenue la base des adresses legacy commençant par « 1 ».
4. P2PKH a été le type de sortie le plus courant pour les paiements ordinaires pendant la majeure partie de l’histoire de bitcoin, et l’est resté pendant des années après l’activation de SegWit en août 2017 au bloc 481 824, car l’adoption du SegWit natif a été progressive. Son succès tenait à sa simplicité et à sa compatibilité ; il ne nécessitait aucune mise à niveau du consensus au-delà des règles du protocole d’origine. Chaque nœud pouvait valider ces scripts de manière indépendante, sans suivi d’état complexe, ce qui en faisait le type de sortie le plus robuste pour les transferts courants pendant les premières années de croissance de Bitcoin.
5. Le format d’adresse utilise l’encodage Base58Check, qui comprend une somme de contrôle de quatre octets pour détecter les fautes de frappe. Un seul caractère mal saisi fera presque certainement échouer la somme de contrôle, et le portefeuille refusera alors l’adresse. Cette redondance a rendu P2PKH convivial malgré sa complexité technique brute, comblant le fossé entre sécurité cryptographique et facilité d’utilisation.
6. Ouvrez un explorateur de blocs et repérez n’importe quelle transaction dont une entrée fait référence à une adresse commençant par « 1 ». Examinez le champ `scriptSig` : il contient la signature suivie de la clé publique sous forme de chaîne hexadécimale. Comparez cette clé publique au hash de 20 octets présent dans le `scriptPubKey` de la sortie référencée. En appliquant SHA-256 puis RIPEMD-160 à cette clé, vous retrouverez le hash stocké, ce qui confirme le lien.

Partie IIPay-to-script-hash (P2SH)

7. Avant 2012, utiliser un script complexe comme une multisignature 5-sur-5 exigeait de placer tout le code de verrouillage directement dans la sortie. Cela rendait la sortie volumineuse, et c’était l’expéditeur qui en payait les frais. Cela exposait aussi les clés publiques de chaque participant ainsi que les exigences de signature précises à quiconque observait la chaîne. L’expéditeur devait connaître la structure exacte de la destination avant d’envoyer, ce qui créait des frictions pour les trésoreries d’entreprise ou les plateformes d’échange ayant besoin de configurations de sécurité flexibles.
8. Gavin Andresen a proposé le BIP16 au début de 2012 pour résoudre ce problème. Il permettait à une sortie de ne contenir que le condensat HASH160 d’un script plutôt que le script lui-même. Le script de sortie est passé à 23 octets, légèrement moins que les 25 de P2PKH. L’expéditeur n’avait plus besoin de connaître les conditions de dépense ; il lui suffisait de payer vers un hash. La complexité était entièrement reportée sur la personne qui dépense les pièces.
9. L’activation du BIP16 en avril 2012 a été controversée. Luke Dashjr a proposé une alternative, le BIP17, qui utilisait un opcode et un schéma d’encodage différents. Le débat sur la proposition à adopter s’est nettement envenimé au sein de la communauté des développeurs. Le BIP16 a été activé en avril 2012 après que les mineurs ont signalé leur soutien, et il est devenu la méthode standard pour encapsuler des scripts complexes.
10. Dépenser une sortie pay-to-script-hash se fait en deux étapes. D’abord, celui qui dépense pousse son script de rachat (redeem script) complet sur la pile. Le nœud vérifie si le HASH160 de ce script correspond au hash présent dans la sortie. S’il ne correspond pas, l’exécution échoue immédiatement. S’il correspond, le nœud exécute alors le script de rachat révélé avec les données restantes sur la pile, afin de vérifier les conditions de dépense réelles.
11. La conception comporte un piège : personne ne peut vérifier le script de rachat avant le paiement, car seul son hash figure on-chain. Si le logiciel du destinataire a construit un script défectueux, ou si le script est perdu, les pièces envoyées à cette adresse peuvent rester à jamais impossibles à dépenser.
12. Lorsque SegWit a été activé en août 2017, P2SH a servi de pont de compatibilité. Les utilisateurs pouvaient encapsuler les nouveaux scripts witness dans une enveloppe P2SH, créant des adresses « imbriquées » (nested) qui commençaient toujours par « 3 ». Les anciens portefeuilles incapables de gérer les nouvelles adresses bech32 pouvaient ainsi continuer à envoyer des fonds aux utilisateurs SegWit, tandis que les destinataires compatibles SegWit bénéficiaient de la réduction de frais au moment de dépenser. Aujourd’hui, si le SegWit natif est préféré pour son efficacité, P2SH reste un mécanisme essentiel pour les contrats complexes et la compatibilité avec l’existant.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• Bitcoin Developer Guide, 'Transactions' documentation (bitcoin.org)
• Satoshi Nakamoto, original Bitcoin client source code (2009-2010 commits)
• Gavin Andresen, BIP16: Pay to Script Hash (2012)
• Luke Dashjr, BIP17: OP_CHECKHASHVERIFY (CHV) (2012)
• Bitcoin Developer Guide: Transactions and Scripts