soft fork : Clients Bitcoin Compatibilité descendante

  • Les règles de compatibilité descendante des clients Bitcoin ont changé au fil du temps
  • Une version 0.1.0 de Bitcoind ne serait pas synchronisée ni fonctionnelle aujourd'hui en raison de changements dans le protocole P2P et la découverte des pairs
  • Les adresses et sorties utilisées par la version 0.1.0 sont toujours valides, mais certains changements politiques comme BIP62 pourraient affecter la capacité à créer des transactions acceptées par le réseau

Je pense que les réponses liées répondent principalement à votre question, mais sinon, permettez-moi d’aborder les exemples spécifiques que vous évoquez.

Je me demande si j’exécutais une version 0.1.0 de Bitcoind aujourd’hui, serait-elle synchronisée et fonctionnerait-elle normalement ?

Ce ne sera pas le cas, mais pas à cause des règles de validité des blocs/transactions qui ont changé, mais parce que le protocole P2P a changé (le paquet initial a maintenant une somme de contrôle depuis 2012, que les nœuds antérieurs à la version 0.2.10 ne prennent pas en charge). Je pense qu’il est possible d’écrire un proxy simple pour résoudre ce problème (qui ajoute simplement la somme de contrôle dans un sens et la supprime dans l’autre), auquel cas un nœud moderne serait capable de communiquer avec un très ancien code Bitcoin.

soft fork : Clients Bitcoin Compatibilité descendante

Un autre problème est que la découverte par les pairs a complètement changé. Un nœud 0.1.0 ne découvrira tout simplement aucune adresse IP de homologues avec qui parler. Ce problème peut être résolu en vous connectant manuellement.

Si je comprends bien, à l’époque, il n’utilisait que P2PK, la version 26.0 le rejetterait-il ?

Ce n’est pas exact. Le format d’adresse « 1. » correspondant aux sorties P2PKH était déjà pris en charge dans la version 0.1.0. De plus, le système de script Bitcoin existe depuis la version 0.1.0 en tant que règles consensuelles. Tous les formats d’adresses modernes sont des scripts valides selon la toute première version. Dans l’autre sens également, les adresses et sorties utilisées par le portefeuille intégré dans la version 0.1.0 (P2PKH et P2PK) sont toujours parfaitement valides et standard par les logiciels modernes, il serait donc en mesure de recevoir des paiements provenant de logiciels modernes.

Si votre question est de savoir si 0.1.0 serait capable d’effectuer des transactions (comme pour créer des transactions acceptées par le réseau), c’est un peu plus délicat. Un certain nombre de consensus et de règles politiques ont changé. Je ne pense pas qu’aucun de ces éléments ait réellement d’importance, à l’exception de la règle de politique low-r BIP62. Cela aurait pour conséquence que seul un faible pourcentage (25 % ou moins, selon les circonstances) des transactions créées par 0.1.0 serait acceptable selon les règles modernes.

en quoi s’agit-il alors d’un soft fork ?

Il s’agissait simplement d’un changement de politique, cela n’a pas affecté les règles de consensus et n’a donc rien à voir avec les softforks.

Il y a eu des softforks (et des hardforks, au tout début) depuis la version 0.1.0, mais aucun n’a réellement d’impact sur la chaîne actuelle. Donc, pour être clair  : ma conviction est que la blockchain Bitcoin actuelle serait entièrement valide selon 0.1.0 (mais voir la réponse liée, elle serait extrêmement lente et nécessiterait des changements de configuration pour ne pas trébucher).