Le développeur de Bitcoin Core, Jeremy Rubin, précipite la communauté Bitcoin dans un essai rapide pour son Miner Activated Soft Fork (MASF). Grâce à sa proposition d’amélioration Bitcoin 119 (BIP-119), il fait pression pour un changement significatif de l’un des codes d’opération de la devise.
Code d’opération proposé par Rubin CheckTemplateVerify introduirait des « clauses restrictives », un nouveau type de transaction conditionnelle. Certains développeurs seniors sont favorables. D’autres fulminent de frustration.
Partout dans le monde, les développeurs de Bitcoin Core contribuent au développement de Bitcoin en révisant le code, en corrigeant les bogues et en débattant de l’avenir de la monnaie. Une fois qu’un développeur croit fermement en un changement majeur, il soumet une proposition formelle connue sous le nom de proposition d’amélioration Bitcoin (BIP).
Les BIP introduisent un nouveau code, qui nécessite un fork pour s’activer. Les mécanismes de consensus de Bitcoin ont des règles pour accepter ou rejeter les fourches. Il y a eu de nombreux forks réussis, notamment SegWit et Taproot.
Rubin a soumis le BIP-119 qui permettrait des clauses restrictives en chaîne. Un exemple d’engagement serait d’envoyer un Bitcoin à quelqu’un qui ne peut alors envoyer ce Bitcoin qu’à une adresse particulière. Les covenants, dans leurs diverses configurations, permettent une programmation et un routage des transactions plus expressifs.
Rubin a proposé d’utiliser un Procès rapide pour parvenir à un consensus pour l’activation du BIP-119. Comme son nom l’indique, Speedy Trials accélère le processus de test pour savoir si une mise à niveau proposée peut obtenir un consensus. La mise à niveau Taproot de Bitcoin, par exemple, a utilisé Speedy Trial pour parvenir à un consensus.
BIP-119 nécessite l’approbation de 90% de la puissance minière du réseau. Cette approche MASF nécessite un quorum de pools de minage pour indiquer son soutien. Les nœuds peuvent ensuite être mis à niveau lorsque la proposition gagne suffisamment de taux de hachage pour être activée.
Contrairement aux fourches souples dirigées par les mineurs, les fourches souples activées par l’utilisateur (UASF) nécessitent l’approbation des nœuds. (Il existe des dizaines de milliers de nœuds complets fonctionnant sur des ordinateurs domestiques dans le monde entier.) SegWit a été activé avec un UASF en 2017, résolvant la controversée Blocksize Wars.
The Blocksize Wars a démontré la difficulté d’activer un changement proposé dans le protocole de Bitcoin. Même les propriétaires de la plupart des plates-formes minières du monde ne pouvaient pas forcer les changements qu’ils voulaient sur Bitcoin. Les utilisateurs (nœuds) ont prévalu. En fin de compte, les partisans des gros blocs ont dû forker, créant d’autres pièces sans accès au client Bitcoin Core et au symbole BTC.
Sommaire
Le développeur de Bitcoin Core, Jeremy Rubin, est un arnaqueur
Jeremy Rubin a fondé Judica, une société de recherche et développement qui se concentre sur un projet smart contract langage de programmation nommé Sapio. Son entreprise serait bénéficier financièrement depuis l’adoption de la BIP-119.
Il a précédemment travaillé sur un algorithme pour améliorer les temps de confirmation des blocs Bitcoin et a également suscité la controverse en suggérer que les mineurs pourraient s’entendre pour réécrire la blockchain de Bitcoin afin de récupérer les fonds perdus à cause du vol.
Le PDG de Binance, Changpeng Zhao, a brièvement examiné la suggestion de Rubin à la suite d’un piratage, mais a rapidement rejeté l’idée après contrecoup d’autres personnalités en Bitcoin.
Que fera le BIP-119 ?
Des clauses très simples comme les portefeuilles multi-signatures et à verrouillage temporel existent déjà dans Bitcoin. La BIP-119 propose des moyens de créer des clauses restrictives plus complexes et programmables.
BIP-119 sera modifier un code opérationOP_CheckTemplateVerify, pour modifier l’OpCode OP_NOP4.
Un OpCode est le premier octet d’une instruction en langage machine qui ordonne au matériel informatique d’effectuer une action. Il définit l’opération que le matériel doit effectuer. Toutes les données supplémentaires telles que les adresses et les valeurs suivent l’OpCode. Tous les processeurs et contrôleurs sont livrés avec un ensemble prédéfini d’OpCodes.
Si la proposition est activée, les utilisateurs peuvent mettre en place des portefeuilles conventionnés où les pièces ne peuvent être dépensées que si elles remplissent certaines conditions prédéterminées. Des conditions peuvent également être ajoutées aux sorties de transactions individuelles non dépensées (UTXO).
OP_CheckTemplateVerify exigera que les conditions suivantes soient vraies :
- Au moins un élément existe sur la pile.
- L’élément sur la pile a une longueur de 32 octets.
- Le DefaultCheckTemplateVerifyHash de la transaction à l’index d’entrée actuel est égal à l’élément sur la pile.
DefaultCheckTemplateVerifyHash contrôle la version sérialisée, le temps de verrouillage, le hachage scriptSigs (le cas échéant, scriptSigs non nul), le nombre d’entrées, le hachage des séquences, le nombre de sorties, le hachage des sorties et l’index d’entrée en cours d’exécution.
Les initiés de Bitcoin expriment des doutes sur le BIP-119
D’éminents Bitcoiners ont remis en question si un essai rapide est approprié pour BIP-119. Sur le dernier Bitcoin Brief de Tone Vays, Adam Back, Jimmy Song et Rodolfo Novak se sont opposés au Speedy Trial de Rubin. Ils ont également révélé une opposition similaire de Peter Todd, Matt Corallo, Giacomo Zucco, Luke-Jr, Bitcoin Gandalf, John Carvalho, Francis Pouliot, Andreas Antonopoulos et de nombreux autres Bitcoiners seniors.
Tous ont diverses raisons de s’opposer au plan, certains étant en faveur du BIP-119 et simplement contre Speedy Trial.
Lire la suite: Le développeur principal veut bifurquer Bitcoin pour une résistance quantique
Il y a diverses préoccupations concernant le BIP-119. Premièrement, les opposants soutiennent qu’il existe diverses propositions d’engagements en chaîne, et il n’est pas clair que le BIP-119 soit nécessairement la meilleure proposition. Deuxièmement, ils sont préoccupés par le calendrier précipité de Speedy Trial, affirmant que les développeurs Core n’ont pas eu suffisamment de temps pour effectuer des audits techniques et de sécurité. Troisièmement, les propriétaires de nœuds et les mineurs pourraient ne pas avoir suffisamment de temps ou d’intérêt pour examiner la proposition de Rubin.
BitcoinMechanic de Start9, par exemple, a suggéré que les nœuds devraient par défaut voter « non » ⏤ rejetant effectivement tous les blocs qui incluent des transactions du BIP-119 de Rubin. BitcoinMechanic approuve un URSF, un soft fork purement défensif pour empêcher Rubin de ce qu’il considère comme un « soft fork malveillant ».
L’auteur de la programmation de Bitcoin, Jimmy Song, a exprimé des doutes sur le fait que BIP-119 puisse obtenir une approbation de 90 % du taux de hachage du réseau. « Je pense que cela n’a aucune chance. Vous allez avoir 20% de mineurs au maximum », a-t-il dit (nous soulignons).
Cependant, Song a averti que la neutralité sur le BIP-119 compterait comme un consentement selon les règles du Speedy Trial.
Jimmy chanson couru un sondage Twitter informel. Sur 240 votes, 54% étaient des « opposants pour l’instant » à OP_CTV et Speedy Trial. 15% étaient partisans d’OP_CTV mais opposés à Speedy Trial. Song a émis l’hypothèse que le nombre de votes inhabituellement bas (il attire normalement des milliers de votes sur un sondage Twitter typique) indiquait que peu de gens comprennent même BIP-119.
Pour des nouvelles plus informées, suivez-nous sur Twitter et Abonnez vous à notre feed ou écoutez notre podcast d’investigation Innové : Blockchain Ville.