Le bulletin de cette semaine annonce une défaillance de consensus corrigée dans les anciennes versions de btcd, décrit les changements proposés à LN pour le relais de transaction v3 et les ancres éphémères, et annonce un nouveau référentiel pour les spécifications liées à Bitcoin. Sont également incluses nos sections régulières avec des annonces de mises à jour et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Divulgation de la défaillance de consensus corrigée dans btcd : Niklas Gögge a utilisé Delving Bitcoin pour annoncer une défaillance de consensus dans les anciennes versions de btcd qu’il avait précédemment divulguée de manière responsable. Les verrous temporels relatifs ont été ajoutés à Bitcoin lors d’une mise à jour logicielle en ajoutant une signification imposée par consensus aux numéros de séquence des entrées de transaction. Afin de garantir que toutes les transactions pré-signées créées avant la mise à jour ne deviennent pas invalides, les verrous temporels relatifs s’appliquent uniquement aux transactions avec des numéros de version supérieurs ou égaux à 2, permettant aux transactions avec la version par défaut originale (version 1) de rester valides avec n’importe quelles entrées. Cependant, dans le logiciel Bitcoin original, les numéros de version sont des entiers signés, ce qui signifie que des versions négatives sont possibles. La section implémentation de référence de BIP68 note que “les versions 2 et supérieures” doivent s’appliquer au numéro de version converti d’un entier signé en un entier non signé, garantissant que les règles s’appliquent à toute transaction qui n’est pas de version 0 ou 1.

    Gögge a découvert que btcd n’implémentait pas cette conversion d’entiers signés en entiers non signés, il était donc possible de construire une transaction avec un numéro de version négatif que Bitcoin Core exigerait de suivre les règles de BIP68 mais pas btcd. Dans ce cas, un nœud pourrait rejeter la transaction (et tout bloc qui la contient) et l’autre nœud pourrait l’accepter (et son bloc), ce qui entraînerait une division de la chaîne. Un attaquant pourrait utiliser cela pour tromper l’opérateur d’un nœud btcd (ou un logiciel connecté à un nœud btcd) en acceptant des bitcoins invalides.

    Le bogue a été divulgué en privé aux mainteneurs de btcd qui l’ont corrigé dans la récente version 0.24.0. Il est fortement recommandé à tous ceux qui utilisent btcd pour l’application du consensus de procéder à la mise à niveau. De plus, Chris Stewart a répondu au fil de discussion de Delving Bitcoin avec un correctif pour la même défaillance dans la bibliothèque bitcoin-s. Les auteurs de tout code pouvant être utilisé pour valider les verrous temporels relatifs de BIP68 sont invités à vérifier le code pour la même faille.

  • ● Changements proposés à LN pour le relais v3 et les ancres éphémères : Bastien Teinturier a publié sur Delving Bitcoin pour décrire les changements qu’il estime devoir être apportés à la spécification LN afin de tirer parti efficacement du relais de transaction v3 et des ancres éphémères. Les changements semblent simples :

    • ● Échange d’ancre : les deux sorties d’ancre actuelles de la transaction d’engagement utilisées pour garantir la capacité de modification des frais CPFP en vertu de la politique de dérogation CPFP sont supprimées et une ancre éphémère est ajoutée à leur place.

    • ● Réduction des retards : les retards supplémentaires de 1-bloc sur la transaction d’engagement sont supprimés. Ils ont été ajoutés pour garantir que la dérogation CPFP fonctionnerait toujours, mais ne sont pas nécessaires dans le cadre de la politique de relais v3.

    • ● Réduction de la redirection : au lieu de dépenser la valeur de tous les HTLC réduits en frais dans la transaction d’engagement, la valeur combinée est ajoutée à la valeur de la sortie d’ancre, garantissant que les frais supplémentaires sont utilisés pour garantir la confirmation à la fois de l’engagement et de l’ancre éphémère (voir le bulletin de la semaine dernière pour plus de détails).

    • ● Autres changements : quelques autres changements mineurs et simplifications sont effectués.

    La discussion ultérieure a examiné plusieurs conséquences intéressantes des changements proposés, notamment :

    • ● Réduction des exigences UTXO : garantir que l’état correct du canal est enregistré on-chain devient plus facile grâce à la suppression du retard supplémentaire de 1-bloc. Si une partie défectueuse diffuse une transaction d’engagement révoquée, l’autre partie peut utiliser sa sortie principale de cet engagement pour augmenter les frais CPFP de cette transaction révoquée. Ils n’ont pas besoin de conserver un UTXO confirmé séparé à cette fin. Pour que cela soit sûr, la partie doit conserver un solde de réserve suffisant, car le minimum de 1 % spécifié dans BOLT2 peut ne pas suffire à couvrir les frais. Pour un nœud non transmetteur qui conserve une réserve suffisante, le seul moment où il a besoin d’un UTXO séparé pour des raisons de sécurité est lorsqu’il souhaite accepter un paiement entrant.

    • ● Logique imbriquée v3 : En réponse aux préoccupations exprimées lors de la réunion de spécification LN selon lesquelles il pourrait prendre beaucoup de temps à LN pour concevoir, mettre en œuvre et déployer ces changements, Gregory Sanders a proposé une étape intermédiaire avec un traitement spécial temporaire des transactions qui ressemblent aux transactions d’engagement LN actuelles de style ancre, permettant à Bitcoin Core de déployer le pool de mémoire en cluster sans être bloqué par le développement de LN. Lorsqu’ils auront été largement déployés et que toutes les implémentations LN auront été mises à niveau pour utiliser la v3, les règles spéciales temporaires pourront être abandonnées.

    • ● Demande de taille maximale de l’enfant : la proposition d’essai pour le relais v3 fixe la taille d’un enfant de transaction non confirmée à 1 000 vbytes. Plus cette taille est grande, plus un utilisateur honnête devra payer pour surmonter un épinglage de transaction (voir le Bulletin #283). Plus la taille est petite, moins d’entrées un utilisateur honnête peut utiliser pour contribuer aux frais.

  • ● Nouveau référentiel de documentation : Anthony Towns a publié sur la liste de diffusion Bitcoin-Dev pour annoncer un nouveau référentiel de spécifications de protocole, Bitcoin Inquisition Numbers And Names Authority (BINANA). Quatre spécifications sont disponibles dans le référentiel au moment de la rédaction :

    • ● BIN24-1 OP_CAT par Ethan Heilman et Armin Sabouri. Voir la description de leur proposition de soft fork dans le Bulletin #274.

    • ● BIN24-2 Déploiements hérétiques par Anthony Towns, décrivant l’utilisation de Bitcoin Inquisition pour les propositions de soft forks et autres modifications sur le signet par défaut. Voir la description détaillée dans le Bulletin #232.

    • ● BIN24-3 OP_CHECKSIGFROMSTACK par Brandon Black, spécifiant cette idée longtemps proposée. Voir la proposition de Black dans le bulletin de la semaine dernière pour inclure cet opcode dans le bundle de soft fork LNHANCE.

    • ● BIN24-4 OP_INTERNALKEY par Brandon Black, spécifiant un opcode pour récupérer la clé interne du taproot à partir de l’interpréteur de script. Cela a également été décrit dans le bulletin de la semaine dernière comme faisant partie du bundle de soft fork LNHANCE.

Bitcoin Optech a ajouté le référentiel BINANA à la liste des sources de documentation que nous surveillons pour les mises à jour, ce qui inclut également les BIP, BOLT et BLIP. Les futures mises à jour peuvent être trouvées dans la section des “principaux changements de code et de documentation”.

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● LDK 0.0.120 est une version de sécurité de cette bibliothèque pour la construction d’applications compatibles LN. Elle “corrige une vulnérabilité de déni de service”qui est accessible à partir d’une entrée non fiable provenant de pairs si l’option UserConfig::manually_accept_inbound_channels est activée.” Plusieurs autres corrections de bugs et améliorations mineures sont également incluses.

  • ● HWI 2.4.0-rc1 est une version candidate pour la prochaine version de ce package fournissant une interface commune à plusieurs périphériques de signature matérielle différents.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’Amélioration Bitcoin (BIPs), Lightning BOLTs, et Bitcoin Inquisition.