Une Guerre Interne Fait Rage Pour Bitcoin Et Un Hard Fork Pourrait Être Le Cas Final

Une tempête se prépare au sein de la communauté des développeurs Bitcoin (BTC), menaçant de fracturer l'écosystème pour la première fois depuis près d'une décennie. Un différend technique concernant l'utilisation de la fonction OP_RETURN de Bitcoin s'est transformé en un affrontement idéologique total qui pourrait aboutir à un Hard Fork. Le conflit remet en question le fondement même de l'objectif du BTC, opposant ceux qui veulent préserver son identité en tant que système monétaire pur à ceux qui le considèrent comme une base pour une innovation plus large.

La controverse autour d'OP_RETURN de Bitcoin

La dernière controverse découle d'une proposition visant à modifier l'opcode OP_RETURN, qui permet d'intégrer des données dans les transactions Bitcoin. Bitcoin Core v30, une mise à jour du logiciel réseau publiée plus tôt cette année, a étendu la limite d'OP_RETURN de 80 octets à 100 000 octets. Ce changement a déclenché une réaction négative parmi les développeurs et les membres de la communauté, craignant qu'il ne transforme le réseau en une couche de stockage pour des données arbitraires, y compris du contenu illégal ou nuisible comme du matériel d'abus sexuel sur enfants (CSAM).

En réponse, le développeur Bitcoin Dathon Ohm a introduit BIP-444, une proposition de hard fork qui vise à restreindre temporairement l'ajout de données arbitraires à la blockchain au niveau du consensus. L'initiative vise à réduire le risque d'intégration de matériel illicite tout en simplifiant la base de code et en préservant sa fonction de réseau monétaire. 

Ohm a souligné sur GitHub que la popularité croissante de Bitcoin et l'adoption généralisée de Bitcoin Core v30 rendaient nécessaire l'avancement de la proposition initialement discutée par le développeur chevronné Luke Dashjr. Il a expliqué que les modèles de déploiement proactifs et réactifs sont en cours de développement, les tests étant toujours en cours. 

La proposition de fork a créé des tensions au sein de la communauté. Les partisans soutiennent que la limitation d'OP_RETURN est essentielle pour protéger les opérateurs de nœuds d'une exposition juridique potentielle, notant que certaines juridictions imposent de lourdes sanctions pour l'hébergement de contenu illégal. Les critiques, cependant, affirment que de telles restrictions contredisent l'éthique de résistance à la censure et de neutralité de Bitcoin. 

Un membre du groupe GitHub insiste sur le fait que Bitcoin ne devrait pas être un système de modération de contenu et que la limitation du stockage de données arbitraires préserve son rôle de monnaie décentralisée. D'autres avertissent que se concentrer sur la légalité pourrait permettre au gouvernement de l'influencer et d'affaiblir ses principes fondamentaux. Ohm a répondu que bien que le réseau lui-même reste sans permission, les individus doivent toujours considérer les conséquences réelles de l'exploitation de nœuds qui pourraient stocker des données interdites. 

La menace imminente d'un Hard Fork

Alors que la controverse et les conflits internes entourant OP_RETURN s'intensifient, les développeurs ont commencé à spéculer ouvertement que la proposition BIP-444 pourrait finalement conduire à un hard fork si un consensus ne peut être atteint. 

D'éminents développeurs Bitcoin avertissent que les enjeux sont considérablement élevés. Dashjr a qualifié l'expansion actuelle d'OP_RETURN de "folie totale", avertissant qu'elle pourrait transformer le réseau en un dépotoir de données plutôt qu'un protocole financier. Un autre développeur, Jason Hughes, vice-président du développement et de l'ingénierie chez Ocean Mining, a accusé les mainteneurs de pousser Bitcoin à devenir un "altcoin sans valeur" et a déclaré qu'un changement de hard fork compromet sa neutralité et pourrait marquer la mort de la cryptomonnaie pionnière. 

D'autres, comme l'ingénieur Bitcoin Peter Todd, ont noté plus tôt cette année que si les développeurs veulent vraiment freiner le spam on-chain et préserver l'efficacité, ils pourraient mettre en œuvre un soft fork, exigeant que chaque chaîne d'octets dans une transaction représente un hash valide ou une clé publique. Une telle approche rendrait la publication de données arbitraires coûteuse mais maintiendrait la compatibilité ascendante.