Soft fork

Chaque mise à jour que le bitcoin a réellement déployée fonctionne ainsi. Resserrer les règles signifie qu'un ancien nœud accepte encore les nouveaux blocs, parce que ceux-ci n'enfreignent aucune des règles qu'il connaît. Les soft forks entre avril 2012 et novembre 2021 ont donné au bitcoin les adresses de hachage de script, les timelocks, SegWit et Taproot, et aucun d'entre eux n'a laissé un portefeuille à la dérive.

Comment cela fonctionne

Un soft fork restreint l'ensemble des blocs valides, de sorte que tout ce que le réseau mis à jour produit était déjà légal selon le règlement précédent.

L'astuce qui rend cela possible est que le langage de script du bitcoin a laissé des portes ouvertes à dessein. Dix opcodes étaient définis comme des no-ops qui réussissent sans rien faire, et les sorties d'un type que personne n'avait encore défini étaient considérées comme dépensables par quiconque pouvait les satisfaire. Un soft fork franchit l'une de ces portes : il prend ce que les anciens nœuds laissent passer et y attache une exigence réelle. OP_NOP2 est devenu OP_CHECKLOCKTIMEVERIFY en décembre 2015 et OP_NOP3 est devenu OP_CHECKSEQUENCEVERIFY en juillet 2016, et pour un nœud de 2014, les deux sont encore des no-ops dans un script qui passe encore.

La conséquence est une répartition des rôles. Les nœuds non mis à jour continuent de vérifier chaque règle qu'ils connaissent et restent sur la même chaîne que tout le monde. Les nœuds mis à jour vérifient davantage. Les mineurs sont le groupe qui doit réellement bouger, car un mineur qui n'a pas mis à jour peut construire un bloc que les nœuds mis à jour rejettent, perdre la récompense et entraîner quiconque le suit sur une branche condamnée.

C'est pourquoi l'activation est la partie difficile plutôt que le code. Si la majorité de la puissance de hachage applique la nouvelle règle, les blocs qui la violent sont orphelins et le resserrement tient. Sinon, le réseau se scinde le long d'une ligne de faille que le soft fork était justement conçu pour éviter. Le bitcoin a essayé plusieurs manières d'établir cette majorité : un décompte de supermajorité des versions de blocs, le schéma de bits de version du BIP-9, les options de délai du BIP-8, et la fenêtre de trois mois de Speedy Trial utilisée pour Taproot.

Un soft fork peut aussi être annulé d'une manière impossible pour un hard fork. Comme la nouvelle règle est une restriction que l'ancien logiciel n'a jamais exigée, l'abandonner remet tout le monde sur une chaîne que toutes les versions considèrent encore comme valide.

Pourquoi cela compte quand vous achetez du bitcoin

Le constat honnête est que les soft forks sont la raison pour laquelle les mises à jour du bitcoin n'ont jamais rien coûté aux détenteurs ordinaires.

Il n'y a pas de migration, pas de date limite, pas d'annonce que vous pouvez manquer. Les bitcoins qui se trouvent à une adresse P2PKH créée en 2013 sont dépensables aujourd'hui par la même clé avec le même logiciel, et chaque soft fork depuis a pris soin de préserver cela. Comparez avec n'importe quelle autre plateforme financière que vous utilisez, et c'est la propriété la plus sous-estimée du système.

Ce que vous remarquez, c'est le décalage, et il se situe aux extrémités. Le protocole active un nouveau type de sortie ; les portefeuilles mettent un an à en faire la valeur par défaut ; les plateformes d'échange mettent plus longtemps à vous laisser retirer vers ce type ; certaines ne le font jamais. Parmi les plateformes d'échange que ce site évalue, la prise en charge de l'envoi vers des adresses bech32 est désormais courante, tandis que la prise en charge des destinations Taproot bech32m reste inégale, soit un décalage de quatre ans sur un changement qui était loi de consensus dès le premier jour. C'est cet écart, et non le protocole, qui décide si vous pouvez réellement utiliser une nouvelle fonctionnalité.

La règle pratique qui en découle est simple. Conservez une adresse d'un type plus ancien pour les plateformes qui n'ont pas encore rattrapé, et vérifiez l'écran de retrait avant de supposer qu'un format fonctionne. Une adresse de retrait rejetée est ennuyeuse ; un ticket d'assistance au sujet d'une adresse acceptée dont le retrait échoue ensuite est pire.

Pay to script hash, le soft fork qui a rendu le multisig utilisable

P2SH est le plus ancien soft fork qui vaut la peine d'être étudié, car il montre le schéma en miniature.

Avant avril 2012, payer vers un arrangement multisig signifiait que le payeur devait inscrire tout le script dans la sortie qu'il finançait. L'expéditeur était ainsi responsable de la politique de sécurité de quelqu'un d'autre, cela produisait des sorties énormes et rendait impossible une adresse imprimée ou énoncée. Le BIP-16 a remplacé tout cela par un hachage de 20 octets du script, enveloppé dans une adresse commençant par le chiffre 3.

Pour un nœud exécutant les anciennes règles, le script de sortie est une comparaison de hachage qui réussit lorsque le dépensier pousse des données correspondantes. Pour un nœud exécutant les nouvelles règles, ces données poussées sont ensuite exécutées comme un script et doivent elles-mêmes être satisfaites. La nouvelle règle est strictement plus forte, donc les anciens nœuds acceptent chaque nouvelle dépense valide, ce qui est la définition d'un soft fork.

L'activation a été désordonnée d'une manière qui s'est répétée depuis. Une proposition concurrente, le BIP-17, a divisé l'opinion des développeurs ; la date limite a glissé du 1er février au 1er avril 2012 ; et les mineurs ont signalé leur soutien en inscrivant la chaîne "/P2SH/" dans les blocs qu'ils minaient. Presque toutes les adresses commençant par 3 qui existent, y compris celles que les plateformes d'échange distribuent pour les dépôts, descendent de cette discussion.

Soft fork vs BIP

Un BIP est un document ; un soft fork est une règle que les nœuds appliquent. Le BIP-341 est un fichier texte dans un dépôt GitHub que n'importe qui aurait pu écrire, tandis que Taproot est ce qui est devenu loi de consensus au bloc 709 632 le 14 novembre 2021. La distinction compte parce que la plupart des BIP ne s'activent jamais, le BIP-17 et les propositions de covenants parmi eux, et parce qu'un seul soft fork couvre souvent plusieurs documents à la fois, comme SegWit l'a fait à travers le BIP-141, le BIP-143, le BIP-144 et le BIP-147. Citer un numéro de BIP quand vous voulez parler d'une règle activée est inoffensif dans une conversation et trompeur lorsque vous essayez de déterminer ce que votre nœud applique réellement.