Règles de consensus

Le règlement est précis à l'extrême : pas de double dépense, pas de sortie valant plus que ses entrées, des scripts valides, et une transaction coinbase qui ne réclame pas plus que la subvention augmentée des frais. Bitcoin Core code en dur les chiffres : 4 000 000 unités de poids par bloc, 80 000 opérations de signature, et une attente de 100 blocs avant que les bitcoins minés puissent être dépensés. Ces règles expliquent pourquoi aucune plateforme d'échange ne peut vous créditer un bitcoin que le réseau n'a jamais créé.

Comment cela fonctionne

Les règles de consensus se divisent en quatre groupes, et presque toutes sont délibérément ternes.

Le premier groupe régit la monnaie. La récompense d'un bloc est divisée par deux tous les 210 000 blocs, et la sortie coinbase ne peut pas réclamer un satoshi de plus que cette subvention augmentée des frais des transactions réellement incluses. Les bitcoins créés par un bloc ne peuvent pas être dépensés avant 100 blocs supplémentaires. Toute autre transaction doit dépenser des sorties qui existent, qui n'ont pas déjà été dépensées, et qui satisfont le script qui les a verrouillées, le total sortant ne dépassant jamais le total entrant.

Le deuxième groupe régit les ressources, car la vérification doit rester assez peu coûteuse pour une machine ordinaire. Un bloc ne peut pas dépasser 4 000 000 unités de poids ni 80 000 unités d'opération de signature. Le troisième groupe régit la structure : la transaction coinbase vient en premier et une seule fois, la racine de merkle dans l'en-tête doit correspondre aux transactions présentes, et le hash de l'en-tête doit se situer au niveau ou en dessous de la cible qu'exigent les règles de difficulté. Le quatrième groupe régit le temps. L'horodatage d'un bloc doit être postérieur à la médiane des onze précédents et ne pas dépasser de plus de deux heures l'horloge propre d'un nœud, et depuis le BIP113 c'est cette même médiane qui sert de référence aux locktimes.

Où ces règles sont écrites, voilà la partie délicate. Il n'existe pas de spécification indépendante : les règles sont ce que le code déployé accepte, ce qui, pour l'immense majorité du réseau, signifie la logique de validation de Bitcoin Core, bizarreries et accidents compris. C'est pourquoi une réécriture dans un autre langage est traitée comme un danger plutôt qu'une amélioration, et pourquoi Bitcoin Knots, la variante la plus connue, conserve le comportement de consensus de Core octet pour octet et ne diffère que par sa politique de relais et de minage.

Modifier la liste se fait dans l'une des deux directions. Un soft fork retire des possibilités, si bien que les blocs produits selon les nouvelles règles paraissent encore valides à l'ancien logiciel : l'encodage strict des signatures DER est devenu obligatoire au bloc 363 725 et OP_CHECKLOCKTIMEVERIFY au bloc 388 381, et ni l'un ni l'autre n'a scindé le réseau. Un hard fork ajoute des possibilités, ce qui fait paraître les nouveaux blocs invalides à quiconque n'a pas mis à jour, et produit deux chaînes sauf adoption universelle.

Pourquoi cela compte quand vous achetez du bitcoin

Les règles de consensus sont la seule partie de la détention de bitcoin que personne ne peut renégocier avec vous après coup.

Elles fixent un plancher ferme sous un petit nombre de risques. Personne ne peut créer des bitcoins hors du calendrier, dépenser une sortie sans sa clé, ni supprimer un paiement enfoui sous un vrai travail. Ce plancher est étroit, et il vaut la peine d'être précis sur ce qui se trouve en dehors, car c'est là que les gens perdent réellement de l'argent : une plateforme d'échange qui devient insolvable, un site d'hameçonnage qui recueille une phrase de récupération, un agent du support qui gèle un compte, une facture fiscale qui arrive sans avoir été budgétée. Aucun de ces cas n'implique qu'une règle a été enfreinte. Ils impliquent de faire confiance à quelque chose que les règles n'ont jamais couvert.

La distinction vous donne un test pour les promesses marketing. Si un service peut annuler un paiement confirmé, il n'a pas annulé une transaction bitcoin ; il a ajusté son propre registre, et vous n'avez jamais été on-chain. Si un produit annonce un règlement plus rapide que ne le permettent les blocs, il vous accorde un crédit et assume le risque lui-même, ce qui peut être un très bon service tant que vous savez que c'est ce que vous avez acheté. Si une cryptomonnaie revendique la sécurité du bitcoin avec des milliers de transactions par seconde, les limites de ressources ci-dessus sont la raison pour laquelle le bitcoin ne le fait pas.

Ce que les règles de consensus ne sont catégoriquement pas, c'est la loi. Le réseau applique les mêmes vérifications à chaque utilisateur de la planète, tandis que le règlement juridique change à chaque frontière, ce qui explique pourquoi les guides pays de ce site existent séparément de tout ce qui figure sur cette page. La validité est décidée par les nœuds. La légalité, les déclarations et le point de savoir si une plateforme d'échange vous acceptera du tout sont décidés par votre juridiction, et les deux n'ont jamais une seule fois accepté de se consulter.

Les 184 milliards de bitcoins qui ont duré cinq heures

Le 15 août 2010, une transaction du bloc 74 638 a créé deux sorties de plus de 92 milliards de bitcoins chacune.

Le bug était arithmétique. Le code vérifiait que chaque sortie était d'un montant raisonnable mais les additionnait en une valeur qui débordait, si bien qu'un total supérieur à toute l'offre prévue se lisait comme un petit nombre positif et passait. Satoshi Nakamoto a publié la version 0.3.10 avec un correctif en quelques heures, les nœuds sont passés à cette version, et une chaîne corrigée a dépassé la chaîne défectueuse 53 blocs plus tard. L'incident est répertorié sous CVE-2010-5139 et reste la seule fois où l'offre de bitcoins a dépassé son calendrier.

Deux leçons subsistent. Le plafond de 21 millions n'est pas une loi de la physique, c'est une ligne de code, et le code peut être faux. Et la réparation a fonctionné précisément parce que personne n'en était responsable : des milliers d'opérateurs indépendants ont chacun choisi d'exécuter le logiciel corrigé, le seul mécanisme qu'une règle de consensus ait jamais eu.

Règles de consensus vs politique de mempool

Les règles de consensus décident de ce qui est valide ; la politique de mempool décide de ce qu'un nœud transmettra. La politique est plus souple, locale, et ajustable par nœud : des frais de relais minimaux par défaut de 1 sat/vB, un seuil de poussière de 546 satoshis sur une sortie legacy, des limites sur les sorties portant des données, et une liste de types de script considérés comme standard. Enfreignez la politique et votre transaction peut simplement ne pas se propager. Enfreignez une règle de consensus et aucun bloc la contenant ne pourra jamais exister. Les mineurs incluent régulièrement des transactions que certains nœuds n'auraient pas relayées, et les blocs qui en résultent sont parfaitement valides, c'est pourquoi « mon portefeuille dit non standard » est un problème d'acheminement qui a des solutions, tandis que « invalide » est définitif.