Lorsqu'il a conçu le prototype de Bitcoin en janvier 2009, Satoshi Nakamoto a dû construire un premier bloc à partir duquel la chaîne s'est allongée. Ce bloc il l'a appelé le bloc de genèse (« genesis block » en anglais) en référence au premier livre de la Torah et de la Bible, qui raconte la création du monde par Dieu.

Par convention, on considère qu'il s'agit du bloc de hauteur 0 (ou « bloc 0 ») au-dessus duquel les autres blocs sont successivement empilés. Examinons plus en détail ce que contient cet élément fondateur de Bitcoin en procédant à une dissection minutieuse !

 

Un bloc fondateur

Le bloc de genèse est une donnée essentielle du protocole Bitcoin car il constitue la base à partir de laquelle on peut déterminer la chaîne la plus longue (c'est-à-dire celle ayant le plus de preuve de travail accumulée) et par conséquent la validité des transactions du registre. Il est théoriquement le seul bloc à devoir être inscrit en dur dans le protocole, même si d'autres l'ont été par la suite.

Tel que l'écrivait Satoshi Nakamoto :

« La chaîne de blocs est une structure en forme d'arbre qui a pour racine le bloc de genèse, chaque bloc pouvant avoir plusieurs candidats à sa suite. »

Le code de novembre 2008 (fourni par Satoshi à Hal Finney, Ray Dillinger et James A. Donald notamment) contenait déjà une première version du bloc de genèse, horodatée au 10 septembre 2008, 18:02:08 UTC. Néanmoins, un nouveau bloc a été construit en janvier 2009 spécialement pour le lancement du prototype.

Le bloc de genèse que nous connaissons est ainsi présent dans la version 0.1 du logiciel de Bitcoin, publiée le 8 janvier 2009. Un commentaire au sein du code le décrit :

Genesis Block:
GetHash()      = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig     = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue       = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime    = 1231006505
block.nBits    = 0x1d00ffff
block.nNonce   = 2083236893
CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
  CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
    CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
  vMerkleTree: 4a5e1e

Ce bloc pèse très exactement 285 octets. Le voici représenté en hexadécimal brut :

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Le bloc de genèse est composé d'un entête de 80 octets et d'une unique transaction, la transaction de récompense. Son identifiant (le résultat du hachage de l'entête par double SHA-256) est 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. Les zéros qui débutent cet identifiant indiquent qu'une preuve de travail a été réalisée.

Notez que les différentes informations contenues dans le bloc sont souvent transmises avec un ordre des octets inverse (dit « little-endian » ou « petit-boutiste »). Nous donnerons ici les informations dans l'ordre ordinaire (qu'on appelle « big-endian » ou « gros-boutiste ») à l'aide du préfixe 0x.

 

L'entête

Comme tous les blocs dans le protocole, le bloc de genèse possède un entête donnant 6 informations différentes. Voici cet entête en détail :

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - identifiant du bloc précédent
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a - racine de Merkle
29ab5f49 - horodatage
ffff001d - valeur cible
1dac2b7c - nonce

 

La version du bloc

0x00000001

La version du bloc indique l'ensemble des règles respectées par le bloc. Cette version 1 indiquait un respect des règles du protocole originel défini par Satoshi. D'autres versions ont été introduites plus tard : la version 2 pour l'application du BIP-34 en mars 2013, la version 3 pour l'activation du BIP-66 en juillet 2015, et la version 4 pour celle du BIP-65 en décembre 2015. Le champ de version a par la suite été utilisé pour que les mineurs signalent leur intention d'appliquer un soft fork (conformément au BIP-9).

 

L'identifiant du bloc précédent

0x0000000000000000000000000000000000000000000000000000000000000000

Puisqu'il s'agit du premier bloc de la chaîne, le champ utilisé pour donner l'identifiant du bloc précédent est fixé à zéro par convention.

 

La racine de Merkle

0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

La racine de Merkle correspond à l'empreinte finale de l'arbre de Merkle des transactions. Puisqu'il n'y a qu'une seule transaction dans le bloc de genèse, il s'agit simplement de l'identifiant de cette transaction.

 

L'horodatage

0x495fab29

L'horodatage indique la date et l'heure à laquelle le mineur a trouvé le bloc. Il est donné par le nombre de secondes depuis le 1^er janvier 1970 00:00:00 UTC. Ici, le nombre correspond à 1 231 006 505 secondes : le bloc de genèse est donc horodaté au 3 janvier 2009 à 18:15:05 UTC.

Toutefois, il ne faut pas croire que cet horodatage indique l'instant précis du lancement effectif du réseau. Ce dernier a en effet été réalisé un peu plus tardivement : le bloc 1 est ainsi horodaté au 9 janvier 2009 à 02:54:25 UTC, soit 5 jours, 8 heures, 39 minutes et 20 secondes plus tard.

 

La valeur cible

0x1d00ffff

La valeur cible est la valeur minimale que l'identifiant du bloc peut avoir pour que ce dernier constitue une solution au problème de preuve de travail de Bitcoin. Moins cette valeur cible est haute, plus il est facile de trouver une solution et de miner un bloc. Elle est donc inversement proportionnelle à la difficulté du réseau.

La valeur cible du bloc de genèse correspond à la plus grande valeur possible dans Bitcoin, ou la difficulté la plus basse pour le dire autrement. Elle est encodée comme un nombre flottant où le premier octet représente un exposant et où la mantisse est déterminée par les 3 octets suivants. Ici, elle est égale à 0x00ffff × 256(0x1d - 3) c'est-à-dire 0x00000000ffff0000000000000000000000000000000000000000000000000000.

La preuve de travail du bloc est valide car l'identifiant est effectivement (largement) inférieur à cette valeur cible :

0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f ≤
0x00000000ffff0000000000000000000000000000000000000000000000000000

On définit la difficulté du minage comme l'inverse de la valeur cible multipliée par la valeur cible de base :

difficulté = cible_de_base / cible

La difficulté du bloc de genèse est donc de 1.

Après le lancement du réseau, la difficulté a stagné à ce niveau pendant près d'un an avant d'enfin commencer à augmenter le 30 décembre 2009.

Au sein du code, le champ de la valeur cible est appelé nBits, car ce paramètre désignait (avant que Satoshi n'en modifie le sens) le nombre de bits de tête à mettre à zéro pour que la solution soit valide. Dans la version de novembre 2008, le champ était en effet fixé à 20, ce qui correspondait à 5 zéros de tête en représentation hexadécimale, soit une valeur cible de 0x00000fffff....

 

Le nonce

0x7c2bac1d

Le nonce (mot qui provient de l'expression anglaise « for the nonce » signifiant « pour la circonstance, pour l'occasion ») désigne le nombre que le mineur fait varier pour calculer la preuve de travail. Il n'a aucune signification particulière, étant déterminé au hasard.

 

L'ensemble des transactions

L'ensemble des transactions forme la seconde partie du bloc. Le voici en détail :

01 - nombre de transactions
01000000 - version
01 - nombre d'entrées
0000000000000000000000000000000000000000000000000000000000000000 - identifiant de transaction de la sortie précédente
ffffffff - index de la sortie précédente
4d - taille du script de déverrouillage
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 - script de déverrouillage
ffffffff - numéro de séquence
01 - nombre de sorties
00f2052a01000000 - montant
43 - taille du script de verrouillage
4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac - script de verrouillage
00000000 - temps de verrouillage

 

Le nombre de transactions

0x01

Le bloc contient une seule transaction : la transaction de récompense qui rémunère le mineur (ici Satoshi) pour la preuve de travail réalisée. Le bloc ne comporte ainsi aucune autre transaction, tout comme les blocs minés dans les premiers jours. Il a fallu attendre le 12 janvier et le bloc 170 pour voir la première transaction effective du réseau être confirmée : celle entre Satoshi et Hal Finney.

Toutes les données restantes du bloc appartiennent à la transaction de récompense.

 

La version de la transaction

0x00000001

La version de la transaction indique comment celle-ci doit être interprétée. Elle est fixée à 1 conformément au protocole initial. Aujourd'hui, il existe également une version 2 qui autorise l'usage des verrous temporels relatifs (voir BIP-68).

 

Le nombre d'entrées de la transaction

0x01

La transaction contient une seule entrée : la base de pièce, ou coinbase, qui permet de créer ex nihilo les nouveaux bitcoins et de recueillir les frais de transaction. Cette entrée est donc purement superflue, mais permet de conserver une certaine cohérence dans l'implémentation logicielle. Elle est constituée des champs identifiant la sortie précédente (théorique), d'un script de déverrouillage et d'un numéro de séquence.

 

L'identifiant de transaction de la sortie précédente

0x0000000000000000000000000000000000000000000000000000000000000000

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant l'identifiant de la transaction qui a créé la sortie. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé à 0 par convention.

 

L'index de la sortie précédente

0xffffffff

Ce champ est utilisé dans les transactions pour dire à quel sortie transactionnelle correspond une entrée, en donnant la position de la sortie dans la transaction qui l'a créée. Puisqu'il s'agit d'une transaction de récompense qui ne fait pas référence à une sortie transactionnelle précédente, ce champ est fixé au maximum par convention.

 

Le script de déverrouillage (scriptSig)

0x04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

Dans Bitcoin, le script de déverouillage est combiné à un script de verrouillage précédent et détermine la validité d'une dépense. Il contient généralement les signatures nécessaires à la dépense d'une pièce et est par conséquent souvent appelé scriptSig. Dans le cas d'une transaction de récompense, l'entrée ne fait référence à aucune sortie transactionnelle existante et ce script peut donc contenir des données arbitraires.

Ici, le script se présente de la manière suivante :

<valeur cible> <nonce supplémentaire> <chaîne de caractères>

Ainsi, il est constitué de trois informations :

• Tout d'abord, la valeur cible du bloc, donnée en sens inverse, conformément à la façon dont elle est représentée dans le code : 0xffff001d
• Ensuite, un nonce supplémentaire (0x04), ou extra nonce, mis en place par Satoshi dans le code du logiciel. Le nonce supplémentaire du bloc de genèse a pour valeur 4, et ceux des blocs suivants sont croissants : celui du bloc 1 est aussi égal à 4, celui du bloc 2 à 11, celui du bloc 3 à 14, etc. La variation de ce nonce supplémentaire au sein des blocs a permis de mettre en évidence un motif particulier, appelé le « Patoshi Pattern », qui détermine précisément les blocs minés par Satoshi et qui démontre que sa fortune s'élève à plus de 1 125 150 bitcoins.
• Enfin, une chaîne de caractères aujourd'hui emblématique, encodée en UTF-8, qui est :

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

  Cette courte phrase correspond à la une du Times du 3 janvier 2009, qui annonçait que le ministre des finances du Royaume-Uni était sur le point de renflouer les banques pour la deuxième fois. Le Times étant un quotidien anglais, cela a mené à des spéculations quant à l'identité de Satoshi, qui écrivait également dans un anglais britannique.

Cette phrase présente dans le script de la transaction de récompense possède un rôle double :

• Premièrement, elle prohibe l'antidatage : sa présence dans le premier bloc, à partir duquel toute la chaîne est construite, prouve que le réseau de Bitcoin n'a pas été lancé avant le 3 janvier 2009. Cependant, cela ne veut pas dire que le bloc de genèse date bien du 3 janvier : en effet, il a pu être construit entre le 3 janvier (date de l'horodatage déclaré) et le 8 janvier (date de publication du code).
• Deuxièmement, elle indique symboliquement ce à quoi Bitcoin s'oppose en faisant référence au contexte monétaire et financier de l'époque : le renflouement des grandes banques d'investissement par les États et par les banques centrales suite à la crise financière de 2007-2008. Il est d'ailleurs possible que Satoshi ait choisi cette date précisément pour sélectionner cette une.

Ce script de la base de pièce est encore utilisé de nos jours par les mineurs pour de multiples raisons. À l'instar de Satoshi, ils peuvent inclure des informations arbitraires dans le bloc et faire passer un message public au monde. Ç'a été le cas de la coopérative F2Pool qui, le 11 mai 2020, a évoqué l'injection de liquidité de la Réserve Fédérale en réaction à la crise du covid-19 au sein du bloc 629 999 (le bloc précédant le troisième halving) :

NYTimes 09/Apr/2020 With $2.3T Injection, Fed's Plan Far Exceeds 2008 Rescue

Les regroupements de mineurs peuvent également s'identifier en indiquant leur nom, ce qui permet de juger de la décentralisation du réseau, même si cette pratique reste purement déclarative.

Enfin, les mineurs se servent encore de ce champ pour faire varier un nonce supplémentaire, le nonce de l'entête ne permettant plus depuis 2012 d'essayer suffisamment de possibilités par rapport à la difficulté élevée du réseau.

 

Le numéro de séquence (nSequence)

0xffffffff

Le numéro de séquence de l'entrée est maximal, ce qui fait que la transaction est considérée comme finale.

À l'origine, le numéro de séquence dans les entrées avait pour objectif de permettre les échanges répétés au sein de contrats, tels que les canaux de paiement. Ce modèle imaginé par Satoshi n'était pas suffisamment sécurisé et a par conséquent été abandonné. Cependant, la règle de finalité, qui fait que la transaction est considérée comme finale (pas de temps de verrouillage) si les numéros de séquence de toutes les entrées sont maximaux (comme ici), a été conservée.

Aujourd'hui, ce numéro de séquence est utilisé pour déterminer le temps de verrouillage relatif d'une entrée et pour signaler Replace-by-Fee.

 

Le nombre de sorties de la transaction

0x01

La transaction contient une seule sortie, celle créditant Satoshi de son revenu de minage. Cette sortie est constituée d'un montant et d'un script de verrouillage.

 

Le montant

0x000000012a05f200

Le montant de la sortie est donné dans la plus petite unité du système, unité qu'on a appelé le satoshi en hommage au créateur de Bitcoin. Ce montant correspond ici à 5 milliards de satoshis, soit 50 bitcoins. Il s'agit de la limite maximale du taux de création monétaire de l'époque (50 bitcoins par bloc).

 

Le script de verrouillage (scriptPubKey)

0x4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Le scrpt de verrouillage est l'ensemble des conditions à fournir pour pouvoir dépenser la pièce correspondante. Ici, il possède la forme :

<clé publique> CHECKSIG

où la clé publique est 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f. Il s'agit donc d'une sortie transactionnelle de type Pay to Public Key (P2PK), un schéma utilisé dans les débuts de Bitcoin, qui demande une simple signature pour débloquer les fonds. Cela explique le nom donné couramment à ce script : scriptPubKey.

Bien souvent, cette sortie est rétrospectivement attribuée à l'adresse 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, obtenue en prenant l'empreinte de la clé publique. Cela est néanmoins purement esthétique car c'est bien la clé publique elle-même qui a servi à recevoir les bitcoins, pas l'adresse.

Fait intéressant : cette sortie transactionnelle n'est pas considérée comme dépensable par le protocole en raison de la façon dont le bloc de genèse est exprimé dans le code. Cette erreur de programmation pourrait être corrigée par un hard fork, mais cela ne serait ni utile (Satoshi n'a pas touché à ses bitcoins depuis qu'il a disparu), ni même souhaitable (incompatibilité du protocole). Les 50 premiers bitcoins créés sont donc probablement brûlés à tout jamais.

 

Le temps de verrouillage (nLocktime)

0x00000000

Le temps de verrouillage (donnée globale appartenant à la transaction) détermine la date à partir de laquelle cette transaction pourra être confirmée. En étant fixé à zéro, celui-ci est désactivé.

 

Les autres chaînes

Si le bloc de genèse constitue un fondement du protocole Bitcoin, il sert également de base aux différentes branches minoritaires de Bitcoin qui possèdent le même historique jusqu'à leurs scissions respectives : Bitcoin Cash, Bitcoin SV, Bitcoin Gold ou encore eCash/XEC. D'autres protocoles possèdent leur propre bloc de genèse et certains d'entre eux ont également incorporé la une d'un journal ou d'un magazine pour garantir que le lancement du réseau ne s'est pas réalisé avant la date donnée. Ainsi, le bloc de genèse de Litecoin (datant du 7 octobre 2011) contient la phrase suivante :

NY Times 05/Oct/2011 Steve Jobs, Apple’s Visionary, Dies at 56

Celui de Dash (datant du 19 janvier 2014) inclut la une suivante :

Wired 09/Jan/2014 The Grand Experiment Goes Live: Overstock.com Is Now Accepting Bitcoins

 

---

Source

Bitcoin Wiki, Genesis block

Bitcoin est un système de monnaie programmable et constitue la première implémentation de ce qu’on appelle les smart contracts ou contrats autonomes. À chaque transaction, des scripts sont exécutés pour vérifier que les fonds dépensés remplissent les conditions voulues par l’utilisateur précédent. De nombreuses conditions sont peuvent être mises en place (divulgation d’un secret, verrou temporel, multisignature), même si le plus souvent les fonds sont simplement dépensés grâce à la signature d’un utilisateur unique.

Bitcoin repose sur un modèle de pièces (UTXO), où chaque pièce est verrouillée par un script incomplet écrit sur la chaîne. Lors d’une transaction, les pièces de bitcoin en entrée sont déverrouillées par un script complémentaire. Puis, de nouvelles pièces sont créées à partir des anciennes grâce à de naouveaux scripts de verrouillage, ce qui perpétue le caractère programmable du système.

Lorsque j’ai découvert comment les transactions fonctionnaient et ce qu’elles permettaient, j’ai été fasciné par l’élégance de cette solution. Néanmoins, en approfondissant ma recherche, j’ai été perturbé par l’existence d’une chose qui différait des autres, une exception : le schéma Pay to Script Hash, qu’on abrège couramment en P2SH.

 

Les différents schémas : P2PK, P2PKH, P2MS et P2SH

Des scripts sont impliqués dans chaque transaction du réseau Bitcoin. Le langage de script est constitué de plus d’une centaine de codes opération, de sorte qu’un large éventail de possibilités s’offre à nous vis-à-vis des conditions qu’on souhaite imposer.

Cependant, dans le but d’améliorer la communication entre les différentes applications et de limiter le risque de perte, certains standards de scripts, ou schémas, ont émergé.

 

P2PK : Pay to Public Key

Le premier schéma s’appelle Pay to Public Key (P2PK), qu’on peut traduire littéralement en français par « payer à la clé publique ». Il s’agit d’envoyer des fonds vers la clé publique (public key) d’un utilisateur, que lui seul pourrait dépenser en signant avec sa clé privée. Le script de verrouillage (parfois appelé scriptPubKey) permettant ce type d’envoi est :

<clé publique> CHECKSIG

Au moment de la dépense, l’utilisateur doit utiliser un script de déverrouillage (parfois appelé scriptSig) contenant simplement sa signature :

<signature>

Pour l’expliquer en français, l’exécution successive de ces deux scripts permet de vérifier que la signature fournie par l’utilisateur correspond à sa clé publique, auquel cas elle est valide.

Si le schéma P2PK était utilisé dans les premiers jours de Bitcoin, notamment pour recevoir les gains de minage, il est aujourd’hui tombé en désuétude au profit d’un schéma rival : P2PKH.

 

P2PKH : Pay to Public Key Hash

Pay to Public Key Hash (P2PKH), littéralement « payer à l’empreinte de la clé publique », est le deuxième type de schéma apparu dans Bitcoin dès le début, grâce à la conception de Satoshi Nakamoto. Ce schéma permet non pas de réaliser un paiement vers une clé publique, mais vers l’empreinte d’une clé publique, et de faire en sorte que le système de script de Bitcoin vérifie quand même que la signature correspond à la clé publique lors de la dépense des fonds. L’empreinte de la clé publique est alors considérée comme la donnée essentielle de l’adresse, qui dans ce cas commence toujours par un 1, comme par exemple 1DzxhUphLFq8FZPGbFgLF8Ssz3hMX9EuMp.

Le script de verrouillage ici est :

DUP HASH160 <empreinte de la clé publique> EQUALVERIFY CHECKSIG

Et le script de déverrouillage est :

<signature> <clé publique>

Pour le dire en français, l’exécution des deux scripts permet de :

• Vérifier que le passage de la clé publique fournie par la fonction de hachage HASH160 (l’empreinte) est égale à l’empreinte qui est spécifiée dans le script ;
• Vérifier la signature fournie correspond à la clé publique fournie.

L’avantage de ce schéma est qu’il permet d’avoir des adresses plus courtes (l’information à encoder n’est que de 20 octets au lieu de 65 octets pour une clé publique), chose pour laquelle Satoshi Nakamoto l’a implémenté. De plus, en ne révélant la clé publique qu’au moment de la dépense, ce schéma accroît aussi la sécurité contre la menace (très hypothétique) de l’ordinateur quantique.

 

P2MS : Pay To MultiSig

Le schéma Pay To MultiSig (P2SH), littéralement « payer à la multisignature », s’est popularisé début 2012. Il s’agit essentiellement d’un schéma qui permet d’exiger la signature de M personnes faisant partie d’un groupe de N participants, via le script de verrouillage :

M <clé publique 1> ... <clé publique N> N CHECKMULTISIG

Le script de déverrouillage correspondant est :

<leurre (0)> <signature 1> ... <signature M>

Pour plus d’informations sur la multisignature, je vous invite à lire mon article sur les adresses multisignatures.

C’est ce schéma, particulièrement exigeant au niveau de la mise en place, qui a motivé la création du schéma P2SH.

 

P2SH

Pay to Script Hash (P2SH), littéralement « payer à l’empreinte du script ». Ce schéma reprend l’idée derrière P2PKH, à la seule différence que la donnée hachée ici n’est pas une clé publique, mais le script lui-même ! Le script en question est alors appelé script de règlement (redeem script) et son empreinte est la donnée constituante de l’adresse, cette dernière commençant toujours par un 3 à l’instar de 3DyDCGSC59yYY46dnRH7Vw1iKbV8zeW36q.

Ce type de schéma a pour avantage de permettre à un utilisateur d’y inclure n’importe quel script et de pouvoir recevoir des fonds de la quasi-totalité des portefeuilles existants. Le fardeau de la construction et du déverrouillage du script revient donc au détenteur de l’adresse, non à celui qui envoie les fonds, ce qui simplifie grandement la communication.

Le script de verrouillage pour le schéma P2SH est :

HASH160 <empreinte du script de règlement> EQUAL

Et le script de déverrouillage est un script de la forme :

[éléments de déverrouillage] <script de règlement>

En français, cela veut dire que le système de script originel de Bitcoin va vérifier que le hachage du script de règlement est égal à l’empreinte inscrite dans le script. Et c’est tout.

Comment ça, « c’est tout » ? Le script de règlement n’est pas exécuté ? N’importe qui connaissant le script pourrait dépenser les bitcoins ?

Comme on va le voir, ce n’est pas le cas et le script de règlement est bien exécuté, bien que ce ne soit pas indiqué explicitement.

 

Règles et exceptions : OP_EVAL et P2SH

Dans la vie, il y a souvent une manière élégante de faire les choses, qui demande parfois plus d’efforts initiaux mais qui préserve l’ordre et la simplicité, et une manière grossière, plus facile à implémenter mais qui complique les choses et crée le désordre.

Ainsi, dans le système législatif d’un pays, il est plus facile de créer et de faire voter de nouvelles lois execeptionnelles que de réformer en profondeur le système. Cette tendance à l’inflation législative fait qu’on se retrouve avec des pays comme la France, qui cumule 73 codes juridiques en vigueur et qui vit de 214 taxes et impôts ainsi que d’une myriade de cotisations sociales.

En informatique comme en droit, l’ajout de nouvelles exceptions crée de la dette technique, rendant le système plus complexe à appréhender, plus difficile à maintenir et plus susceptible de ne pas fonctionner comme attendu. P2SH fait partie de ces exceptions.

 

Le code opération mort-né : OP_EVAL

L’idée d’implémenter un schéma de script qui utilise l’empreinte d’un autre script comme identifiant est née en 2011, afin de reproduire ce qui est réalisé dans la schéma P2PKH. Toutefois, cette idée n’a pas été développée initialement comme P2SH, mais à travers OP_EVAL, un nouveau code opération permettant l’exécution récursive d’un script à l’intérieur d’un autre script.

L’ajout de ce code opération, proposé le 18 octobre 2011 par Gavin Andresen, devait être implémenté comme un soft fork, via le remplacement de l’instruction nulle OP_NOP1.

Un schéma standard aurait également été ajouté. Le script de verrouillage imaginé pour ce schéma était :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

Le script de déverrouillage correspondant était :

[éléments de déverrouillage] <script de règlement>

Pour le dire en français, l’exécution des deux scripts côte à côte aurait permis de :

• Vérifier que le hachage du script de règlement soit égal à l’empreinte spécifiée dans le script de verrouillage ;
• Vérifier que l’exécution du script de règlement combiné aux éléments de déverrouillage soit bien valide.

Néanmoins cette solution n’a pas été acceptée, celle-ci ayant été jugée trop dangereuse au niveau du pouvoir de récursion. À la place c’est un autre modèle, plus restrictif, qui a prévalu : le schéma P2SH.

 

Comment fonctionne P2SH ?

P2SH a été proposé le 3 janvier 2012 comme alternative à OP_EVAL et à d’autres propositions. Il a été intégré au protocole Bitcoin le 1^er avril sous la forme d’un soft fork activé par les mineurs.

L’exécution de ce type de script fonctionne exactement comme le schéma lié à OP_EVAL, à l’exception qu’une partie du script n’est pas explicitement indiquée. D’une part, la vérification de la correspondance entre l’empreinte indiquée et le script de règlement est bien réalisée par le script de verrouillage. En effet, celui-ci devient (comme on l’a vu) :

DUP HASH160 <empreinte du script de règlement> EQUALVERIFY EVAL

D’autre part, l’évaluation du script de règlement est effectuée implicitement grâce à une exception ajoutée au code source. Dès que les nœuds du réseau reconnaissent le schéma, ils l’interprètent différemment. Ainsi dans Bitcoin Core, on peut observer la condition suivante au sein de la fonction VerifyScript de l’interpréteur :

// Additional validation for spend-to-script-hash transactions:
if ((flags & SCRIPT_VERIFY_P2SH) && scriptPubKey.IsPayToScriptHash())
{
    ...
}

Cette exception permet l’exécution du script de règlement après l’exécution des deux scripts (déverrouillage et verrouillage). D’où le fait qu’on indique les éléments de déverrouillage avant de pousser le script de règlement dans le script de déverrouillage :

[éléments de déverrouillage] <script de règlement>

Si cette solution est pratique, elle crée une complexité et n’est pas très élégante. Comme l’a dit Gavin Andresen dans l’explication du BIP-16 :

Reconnaître une forme « spéciale » de scriptPubKey et réaliser une validation supplémentaire quand elle est détectée, c’est laid. Cependant, l’avis général est que les alternatives sont soit encore plus laides, soit plus complexes à implémenter, et/ou étendent le pouvoir du langage d’expression de manière dangereuse.

L’implémentation initiale de P2SH a donc compliqué les choses. Mais cela ne s’est pas arrêté pas là, car l’activation de SegWit en 2017 a ajouté de la complexité au modèle.

 

SegWit, P2SH-P2WPKH et P2SH-P2WSH

En août 2017, la mise à niveau SegWit a été intégrée à Bitcoin (BTC) sous la forme d’un soft fork. Celle-ci avait pour objectif de corriger la malléabilité des transactions, d’augmenter la capacité transactionnelle, d’améliorer la vérification des signatures et de faciliter les modifications futures du protocole.

Pour ce faire, SegWit implémentait un nouveau modèle de transaction, où les signatures sont situées dans une partie séparée de la transaction appelée le témoin (d’où le nom de Segregated Witness). Afin d’implémenter ce changement comme un soft fork, il a été nécessaire d’introduire un moyen d’accéder au nouveau type de transaction sans briser la compatibilité avec les anciennes adresses.

C’est ainsi que 4 nouveaux types d’adresse ont vu le jour : deux nouveaux types « natifs », P2WPKH (Pay to Witness Public Key Hash) et P2WSH (Pay to Witness Script Hash), incompatibles avec portefeuilles ne supportant pas SegWit ; et deux types « imbriqués » associés, P2SH-P2WPKH et P2SH-P2WSH, qui permettent la transition grâce à l’emploi de P2SH.

Pour ces deux derniers types d’adresse, le schéma utilisé est P2SH avec un script de règlement de la forme :

<version SegWit> <empreinte>

Dans la version 0 de SegWit (la seule qui existe pour le moment), l’empreinte est affectée à une clé publique ou à un script selon sa longueur : si elle est de 20 octets, elle est interprétée comme une empreinte de clé publique ; si elle est de 32 octets, elle est interprétée comme une empreinte de script. Cette empreinte est aussi appelée « programme ».

Ce script est anyone-can-spend puisque le script de règlement suffit à déverrouiller la pièce :

<script de règlement>

Comme pour P2SH, la connaissance du script de règlement ne suffit pourtant pas à dépenser les fonds, car une nouvelle exception est ajoutée au code de façon à ce que les éléments de déverrouillage soient transférées dans le témoin. Dans Bitcoin Core, cette exception se traduit par :

// P2SH witness program
if (flags & SCRIPT_VERIFY_WITNESS) {
    ...
}

SegWit a ainsi apporté un nouveau lot de complexité, et notamment un deuxième niveau de récursion. Dans le cas du schéma P2SH-P2WSH, on a en effet une série de 3 scripts imbriqués. Le premier script est le script de déverrouillage que l’on a présenté au début de cet article :

HASH160 <empreinte du script de règlement> EQUAL

Le deuxième script est le script de règlement spécifique à P2SH :

<version SegWit> <empreinte du script SegWit>

Le troisième est le script SegWit, indiqué dans le témoin avec les éléments de déverrouillage au moment de la dépense des fonds. Par exemple, il peut s’agir d’un script de multisignature comme vu précédemment :

2 <clé publique 1> <clé publique 2> 2 CHECKMULTISIG

qu’on complète avec les éléments :

0 <signature 1> <signature 2>

 

Conclusion

Pay to Script Hash (P2SH) est donc une manière imparfaite mais très pratique de permettre aux utilisateurs de payer à l’empreinte d’un script, c’est-à-dire à une adresse simple qui correspond à un script. La récursion qui intervient dans l’exécution du script aurait pu être implémentée de manière plus élégante grâce au code opération OP_EVAL, mais ce dernier a été jugé trop dangereux par la communauté pour voir le jour.

En ajoutant une nouvelle exception au protocole pour être exécuté, le schéma P2SH représente un vecteur de complexité. De plus, cette complexité est démultipliée par l’incorporation de SegWit, qui ajoute de nouvelles exceptions rigides à P2SH et qui finit de détourner complètement le fonctionnement originel du système de script de Bitcoin.

Néanmoins, ce qui est fait est fait, et aujourd’hui ces changements commencent à être connus dans l’écosystème, et on peut donc espérer que cette complexité n’impacte pas trop les nouveaux développeurs. En particulier, le schéma P2SH est répandu dans tout l’écosystème, par les protocoles associés à Bitcoin tel que Bitcoin Cash, Litecoin ou Dash. Seuls les développeurs de Bitcoin SV ont se sont opposés à cette particularité de manière catégorique et ont choisi de désactiver P2SH en février 2020.

Ce qu’il faut retenir de tout ceci, c’est que Bitcoin, au-delà de son aspect technique, est un système économique et social. Il évolue selon les exigences de ses utilisateurs, si bien qu’il est impossible de le comprendre sans appréhender les dynamiques sous-jacentes qui ont été à l’œuvre dans le passé.

 

---

Sources

Gavin Andresen, BIP-11 (M-of-N Standard Transactions), 18 octobre 2011.
Gavin Andresen, BIP-12 (OP_EVAL), 18 octobre 2011.
Gavin Andresen, BIP-16 (Pay to Script Hash), 3 janvier 2012.
Mike Hearn, On consensus and forks, 12 août 2015.
Eric Lombrozo, Johnson Lau et Pieter Wuille, BIP-141 (Segregated Witness), 21 décembre 2015.