Fonctionnalités avancées du Bitcoin

Cet article complète Comment fonctionne le Bitcoin ? en rentrant plus en profondeur dans le protocole Bitcoin. Les thèmes abordés sont: les scripts de verrouillage, les formats d’adresse, la multisignature et le verrouillage temporel.

Les scripts de transaction

Dans l’article Comment fonctionne le Bitcoin ?, nous avons vu qu’un script de verrouillage (champ ScriptPubKey) est associé à chaque sortie de transaction et un script de déverrouillage (champ ScriptSig) à chaque entrée. Le script de verrouillage spécifie les conditions à satisfaire pour que la dépense des bitcoins associés soit autorisée. Le script de déverrouillage est un script qui va satisfaire ces conditions et donc permettre cette dépense.

Des scripts de verrouillage, il en existe plusieurs types que nous n’allons pas tous aborder. Dans cet article nous nous intéressons aux principaux c’est-à-dire les P2PKH, P2SH, P2WPKH et P2WSH: 

• Le plus utilisé est le P2PKH (Pay to Public Key Hash). Il verrouille la sortie de transaction à l’empreinte d’une clef publique transmise via une adresse Bitcoin au format P2PKH. Cet UTXO verrouillé par un script P2PKH ne peut être dépensé que par la fourniture de la clef publique et d’une signature créée par la clef privée correspondante.

• Le type de script P2SH (Pay to Script Hash) introduit en 2012, verrouille la sortie de transaction à l’empreinte d’un script de récupération (reedem script) détaillant les conditions à satisfaire pour pouvoir la dépenser. Ce script de récupération n’est pas présent dans le script de verrouillage (champ ScriptPubKey), seule est présente son empreinte. Pour qu’une transaction puisse dépenser cet UTXO, elle devra contenir le script de récupération qui correspond à l’empreinte, en plus des éléments de déverrouillage. Un script de récupération peut contenir une ou plusieurs clefs publiques. Les éléments de déverrouillages peuvent-être des signatures et/ou des instructions.

• Le type de script P2WPKH (Pay to Witness Public Key Hash) est apparu avec la mise à jour logicielle relative au Témoin séparé (Segregated Witness). Il verrouille la sortie de transaction à l’empreinte d’une clef publique transmise via une adresse Bitcoin au format Bech32. Cet UTXO ne peut être dépensé que par la fourniture de la clef publique et d’une signature créée par la clef privée correspondante. La différence avec le type P2PKH est que la clef publique et la signature ne plus fournies dans le champ « ScriptSig » de la transaction, mais dans une nouvelle structure appelée « Segregated Witness » ou « SegWit » (témoin séparé) qui ne sera pas utilisée pour le calcul de l’empreinte de la transaction. L’utilisation du P2WPKH plutôt que P2PKH permet de corriger une faille de sécurité sur la malléabilité des transactions qui peut être problématique selon son utilisation.

• Le type de script P2WSH (Pay to Witness Script Hash) est également apparu avec la mise à jour logicielle relative au Témoin séparé (Segregated Witness). Il verrouille la sortie de transaction à l’empreinte d’un script détaillant les conditions à satisfaire pour pouvoir la dépenser. La différence avec le type P2SH est que le script est appelé script témoin (witness script) et qu’il n’est plus fourni dans le champ « ScriptSig » de la transaction, mais dans une nouvelle structure appelée « Segregated Witness » ou « SegWit » (témoin séparé) qui ne sera pas utilisée pour le calcul de l’empreinte de la transaction. L’utilisation du P2WSH permet de corriger une faille de sécurité sur la malléabilité des transactions et de diminuer les frais du fait de la réduction de la taille des transactions. Les canaux de paiement du Lightning Network reposent sur ce type de script P2WSH.

Le nouveau format de transaction avec Segregated Witness (utilisé par les types P2WPKH et P2WSH) est défini dans la BIP 141 (Bitcoin Improvement Proposal 141). Il diffère de l’ancien format par l’ajout de 3 nouveaux champs de données:

• Le champ « Marker » permet de différencier ce nouveau format de transaction (Segregated Witness) de l’ancien. L’écriture de la valeur zéro dans cet octet permet la rétrocompatibilité avec les nœuds qui n’auraient pas réalisé la mise à jour logiciel pour gérer ce nouveau format.

• La champ « Flag » est un champ de bits signalant les champs supplémentaires présents dans ce nouveau format Segregated Witness. Aujourd’hui seule la valeur 1 est définie pour indiquer la présence du script de verrouillage dans cette structure extérieure à la transaction. D’autres valeurs seront possibles à l’avenir.

• La structure « Witness » contient toutes les données témoins de la transaction. Actuellement, le seul type de données témoins supporté est celui pour le déverrouillage des entrées de la transaction.

Les formats d’adresse

Il existe plusieurs formats d’adresse Bitcoin, chaque format fonctionne de façon spécifique et possède une méthode d’identification unique. Voici les 3 principaux:

• Le format d’adresse P2PKH est le format d’adresse traditionnel. L’adresse P2PKH est construite à partir de l’empreinte de la clef publique qui est elle-même dérivée de la clef privée (comme détaillé dans l’article Comment fonctionne le Bitcoin ?). Une adresse P2PKH commence par le préfixe « 1 ».

• Le format d’adresse P2SH est défini par la BIP 16. L’adresse P2SH est créée de la même façon qu’une adresse P2PKH c’est-à-dire en utilisant les fonctions de hachage SHA256 et RIPEMD160 puis l’algorithme d’encodage Base58check. La différence est qu’en entrée de cette suite de fonctions se trouve le code source du script de récupération P2SH au lieu de la clef publique de l’utilisateur. Une adresse P2SH commence par le préfixe « 5 ».

• Le format d’adresse Bech32 est utilisé pour les transactions utilisant le nouveau format avec Segregated Witness détaillé au chapitre précédent. Il peut être construit avec deux types d’entrés: la clef publique du bénéficiaire dans le cas d’un script P2WPKH ou un script témoin (witness script) dans le cas d’un script P2WSH. Une adresse Bech32 commence par le préfixe « bc1 ». C’est la longueur de l’empreinte portée par l’adresse Bech32 qui va permettre à l’application logicielle de déterminer s’il s’agit d’un script P2WPKH ou P2WSH.

La multisignature

L’application la plus courante des transactions de type P2SH et P2WSH est la fonctionnalité multisignature, qui comme son nom l’indique, exige plus d’une signature pour prouver la propriété des fonds et donc pour les dépenser. Une adresse portant cette fonctionnalité est également désignée sous le terme de « M-of-N multisig » avec M désignant le nombre de signatures requises pour débloquer les fonds et N le nombre total de signatures associées à ce fond.

Ainsi dans l’exemple d’une adresse 2-of-3 multisig (signature de 2 parmi 3) ci-dessus, 2 signatures sont suffisantes pour accéder aux fonds d’une adresse à 3 signatures. 

Le verrouillage temporel (TimeLock)

Le protocole Bitcoin offre la possibilité de créer des limites temporelles sur la dépense de fonds. Ces verrouillages temporels peuvent être réalisés au niveau de la transaction elle-même ou bien au niveau de l’UTXO (la sortie de transaction).

Le verrouillage temporel au niveau de la transaction

Lorsque le verrouillage temporel est défini au niveau de la transaction, il n’est pas possible pour un nœud du réseau de propager cette transaction à l’ensemble du réseau Bitcoin avant l’heure définie. Effectuer un verrouillage temporel au niveau de la transaction c’est ajouter un élément à la liste des critères que vérifie chaque nœud avant de transférer une transaction à ses voisins. Pour plus d’information sur le partage et la vérification d’une nouvelle transaction, je vous invite à vous reporter à l’article Comment fonctionne le Bitcoin ?.
Il existe 2 champs différents dans la structure de données d’une transaction pour effectuer un verrouillage temporel selon que l’on veut spécifier une date au plus tôt ou délai minimum.

• Le champ Locktime de la structure permet d’exprimer une date absolue. Cette date peut être exprimée en hauteur de blocs ou en horodatage Unix. Une date exprimée en hauteur de blocs signifie que la transaction n’est pas valide et n’est pas relayée ou incluse dans la blockchain avant que la hauteur de bloc spécifiée ne soit atteinte. (Pour rappel, toutes les 10 minutes un nouveau bloc est ajouté à la blockchain Bitcoin). Une date exprimée en horodatage Unix n’est pas valide avant l’heure spécifiée (calculée en secondes depuis le 1er janvier 1970).
• Depuis la BIP 68, le champ Sequence localisé dans la structure des données d’entrée d’une transaction permet d’exprimer un délai avec pour référence la date d’inclusion de l’UTXO dans la blockchain. Cette durée peut être exprimée en hauteur de blocs ou temps écoulé (avec une granularité de 8 minutes pour cette dernière possibilité). Le verrouillage temporel étant effectué au niveau des entrées, une même transaction peut avoir plusieurs conditions de temps différentes. Dans ce cas, la transaction ne sera valide que si toutes les conditions sont remplies.

Il est important de noter que lorsque le verrouillage temporel est uniquement défini au niveau de la transaction, le destinataire n’est pas certain d’obtenir les fonds promis une fois les conditions temporelles satisfaites. En effet, le débiteur a la possibilité d’effectuer une dépense du même UTXO pour un autre destinataire pendant que le 1er destinataire attend la validité de sa transaction. Dans ce cas, Bitcoin interdisant la double dépense d’un UTXO, le 1er destinataire ne recevra jamais les fonds.

Le verrouillage temporel au niveau de l’UTXO

La réalisation d’un verrouillage temporel au niveau de l’UTXO s’effectue par l’utilisation d’instructions dédiées dans un script de récupération (script P2SH) ou un script témoin (script P2WSH). Il existe 2 instructions distinctes pour le verrouillage temporel: l’instruction CheckLockTimeVerify qui permet de spécifier une date absolue et l’instruction Checksequenceverify qui permet de spécifier un délai minimum.

• L’instruction CheckLockTimeVerify (CLTV) définie par la BIP 65 permet de créer une transaction Bitcoin dont l’UTXO ne peut être dépensé qu’une fois atteint le moment spécifié dans le futur. Ainsi, les fonds envoyés dans cette transaction sont verrouillés dans le temps jusqu’à une date spécifiée, ou jusqu’à ce qu’un certain nombre de blocs aient été minés. Comme pour le champ Locktime d’une transaction, la date de verrouillage peut être exprimée en hauteur de blocs ou en horodatage Unix.
• L’instruction  Checksequenceverify (CSV) définie par la BIP 112 permet de définir un délai au bout duquel la dépense de l’UTXO est autorisée. Ce délai est calculé à partir de la date d’inclusion de la transaction (incluant l’UTXO) dans la blockchain. Comme pour le champ Sequence ce délai peut-être en hauteur de blocs ou temps écoulé (avec une granularité de 8 minutes pour cette dernière possibilité).                    

Le verrouillage temporel au niveau de l’UTXO peut être effectué indépendamment ou en combinaison avec un verrouillage temporel au niveau de la transaction.

Pour conclure

J’espère avec cet article vous avoir éclairé sur les fonctions avancées du Bitcoin. N’hésitez pas à partager vos commentaires pour l’améliorer.