Hoskinson de Cardano dit que le correctif quantique de Bitcoin ne peut pas sauver le BTC de Satoshi Nakamoto

Hoskinson de Cardano dit que le correctif quantique de Bitcoin

Les principaux développeurs de Bitcoin ont proposé plus tôt cette semaine de geler 8 millions de pièces pour se défendre contre les attaquants quantiques.

Mais le fondateur de Cardano, Charles Hoskinson, estime qu’il ne peut toujours pas sauvegarder les pièces appartenant au créateur pseudonyme du réseau, Satoshi Nakamoto, selon une vidéo publiée sur sa chaîne YouTube mercredi soir.

Hoskinson a déclaré que la défense proposée par Bitcoin contre les ordinateurs quantiques est à la fois techniquement mal étiquetée et structurellement incapable de protéger les pièces les plus anciennes du réseau, y compris les quelque 1 million de bitcoins attribués à Satoshi Nakamoto.

Il a fait valoir que le BIP-361, la proposition du développeur Jameson Lopp et d’autres visant à éliminer progressivement les adresses Bitcoin vulnérables quantiquement, est présenté comme un soft fork mais nécessiterait fonctionnellement un hard fork car il invalide les schémas de signature existants sur lesquels les utilisateurs s’appuient activement.

« Pour faire cela, vous avez besoin d’un hard fork », a déclaré Hoskinson. La distinction est importante car la culture de développement de Bitcoin s’est historiquement opposée aux hard forks, les considérant comme des violations de l’immuabilité du réseau. Les auteurs du BIP-361 ont décrit la proposition comme un soft fork, une caractérisation que Hoskinson a qualifiée de mensonge.

Un soft fork resserre les règles afin que les anciens logiciels fonctionnent toujours mais ne peuvent pas utiliser les nouvelles fonctionnalités. Un hard fork change les règles si fondamentalement que les anciens logiciels cessent complètement de fonctionner et que le réseau se divise à moins que tout le monde ne mette à niveau.

BIP-361 suggère que les utilisateurs disposant de fonds gelés et vulnérables quantiquement pourraient les récupérer en construisant une preuve sans connaissance liée à leur phrase de départ BIP-39, une norme pour générer des clés de portefeuille à partir d’une phrase récupérable.

Hoskinson a fait valoir que cette approche ne pouvait pas sauver environ 1,7 million de bitcoins antérieurs à l’introduction du BIP-39 en 2013, y compris environ 1 million de pièces associées aux premières activités minières de Satoshi.

Ces premières pièces ont été générées à l’aide d’une méthode de dérivation de clé différente de celle du logiciel de portefeuille Bitcoin d’origine, qui reposait sur un pool de clés local plutôt que sur une graine déterministe.

Il n’existe pas de phrase de départ pour prouver la connaissance, ce qui signifie qu’aucun système de récupération de connaissance nulle fondé sur cette hypothèse ne peut restituer l’accès aux détenteurs.

« 1,7 million de pièces ne peuvent pas faire cela. Ce n’est pas possible. Dont 1,1 million appartiennent à Satoshi », a déclaré Hoskinson.

Si la proposition est adoptée sous sa forme actuelle, ces pièces resteront définitivement gelées, que leurs propriétaires d’origine tentent ou non de migrer, car la migration nécessiterait une preuve cryptographique qu’ils ne sont pas en mesure de fournir.

Jameson Lopp, le développeur principal qui a co-écrit le BIP-361, a reconnu dans un article sur X cette semaine qu’il n’aime pas la proposition et espère qu’elle n’aura jamais besoin d’être adoptée, la décrivant comme « une idée approximative d’un plan d’urgence » plutôt que comme une spécification finalisée.

Lopp a fait valoir qu’il serait préférable de geler les pièces dormantes, qu’il estime à 5,6 millions de bitcoins, plutôt que de permettre à un futur attaquant quantique de les récupérer et de les jeter sur le marché.

La critique plus large de Hoskinson s’étend au-delà des détails techniques. Il fait valoir que le manque de gouvernance formelle en chaîne de Bitcoin laisse le réseau incapable de résoudre ces compromis par le biais d’un processus structuré, obligeant les mises à niveau controversées à être négociées via les listes de diffusion des développeurs et la pression sociale.

Laisser un commentaire