Le bulletin de cette semaine décrit un changement potentiel dans Bitcoin Core affectant les mineurs, résume la discussion sur la création de verrous temporels relatifs au niveau des contrats, et discute d’une proposition pour une variante de LN-Symmetry avec des pénalités optionnelles. Sont également incluses nos sections régulières annoncant des mises à jour et des versions candidates, et résumant les changements notables dans les principaux logiciels d’infrastructure Bitcoin.

Nouvelles

• ● Enquête sur le comportement des pools de minage avant de corriger un bug de Bitcoin Core : Abubakar Sadiq Ismail a posté sur Delving Bitcoin à propos d’un bug découvert en 2021 par Antoine Riard qui résulte en ce que les nœuds réservent 2 000 vbytes dans les modèles de bloc pour les transactions coinbase plutôt que les 1 000 vbytes prévus. Chaque modèle pourrait inclure environ cinq transactions petites supplémentaires si la double réservation était éliminée. Cependant, cela pourrait conduire les mineurs qui dépendent de la double réservation à produire des blocs invalides, entraînant une grande perte de revenus. Ismail a analysé les blocs passés pour déterminer quels pools de minage pourraient être à risque. Il a noté que Ocean.xyz, F2Pool et un mineur inconnu semblent utiliser des paramètres non par défaut, bien qu’aucun d’entre eux ne semble être à risque de perdre de l’argent si le bug est corrigé.

  Cependant, pour minimiser le risque, il est actuellement proposé d’introduire une nouvelle option de démarrage qui réserve par défaut 2 000 vbytes pour le coinbase. Les mineurs qui n’ont pas besoin de rétrocompatibilité peuvent facilement réduire la réservation à 1 000 vbytes (ou moins, s’ils ont besoin de moins).

  Jay Beddict a relayé le message à la liste de diffusion Mining-Dev.

• ● Verrous temporels relatifs au niveau des contrats : Gregory Sanders a évoqué sur Delving Bitcoin la recherche d’une solution à une complication qu’il a découverte il y a environ un an (voir le Bulletin #284) lors de la création d’une implémentation de preuve de concept de LN-Symmetry. Dans ce protocole, chaque état de canal peut être confirmé onchain, mais seul le dernier état confirmé avant une date limite peut distribuer les fonds du canal. Habituellement, les parties d’un canal essaieraient de confirmer uniquement le dernier état ; cependant, si Alice initie une nouvelle mise à jour de l’état en signant partiellement une transaction et en l’envoyant à Bob, seul Bob peut compléter cette transaction. Si Bob stagne à ce moment-là, Alice ne peut fermer un canal que dans son avant-dernier état. Si Bob attend que l’avant-dernier état d’Alice ait presque atteint sa date limite et confirme ensuite le dernier état, cela prendra environ deux fois plus de temps que la date limite pour que le canal se résolve, ce qu’on appelle le problème de délai 2x. Cela signifie que les verrous temporels pour les HTLCs dans LN-Symmetry doivent être jusqu’à deux fois plus longs, ce qui permet aux attaquants d’empêcher plus facilement les nœuds de transfert de générer des revenus sur leur capital (à travers les attaques de blocage de canal et autres.

  Sanders suggère de résoudre le problème avec un verrouillage temporel relatif qui s’appliquerait à toutes les transactions nécessaires pour régler un contrat. Si LN-Symmetry disposait d’une telle fonctionnalité et qu’Alice confirmait l’avant-dernier état, Bob devrait confirmer le dernier état avant la date limite de l’avant-dernier état. Dans un article ultérieur, Sanders renvoie à un protocole de canal par John Law (voir le Bulletin #244) qui utilise deux verrouillages temporels relatifs au niveau de la transaction pour fournir un verrouillage temporel relatif au niveau du contrat sans changements de consensus. Cependant, cela ne fonctionne pas pour LN-Symmetry qui permet à chaque état de dépenser à partir de n’importe quel état précédent.

  Sanders esquisse une solution, mais note qu’elle a des inconvénients. Il note également comment le problème pourrait être résolu en utilisant la fonctionnalité coinid de Chia, qui semble être similaire à l’idée de John Law en 2021 pour les Identifiants Hérités (IIDs). Jeremy Rubin a répondu avec un lien vers sa proposition de l’année dernière pour les sorties muon qui doivent être dépensées dans le même bloc que la transaction qui les a créées, montrant comment elles pourraient contribuer à une solution. Sanders mentionne, et Anthony Towns développe, la fonctionnalité coinid de la blockchain Chia, montrant comment elle pourrait réduire les données requises à une quantité constante. Salvatore Ingala a évoqué un mécanisme similaire utilisant OP_CAT qu’il a appris du développeur Rijndael, qui plus tard a fourni des détails. Brandon Black a décrit une solution alternative—une variante de LN-Symmetry basée sur des pénalités—et a cité le travail de Daniel Roberts à ce sujet (voir le prochain article du bulletin).

• ● Variante de LN-Symmetry multipartite avec des pénalités pour limiter les publications de mises à jour : Daniel Roberts a publié sur Delving Bitcoin un article sur la façon d’empêcher qu’une contrepartie malveillante de canal (Mallory) soit capable de retarder le règlement du canal en diffusant délibérément de vieux états à un taux de frais plus élevé que celui qu’une contrepartie honnête (Bob) paie pour la confirmation de l’état final. En théorie, Bob peut relier son état final à l’ancien état de Mallory et les deux transactions pourraient se confirmer dans le même bloc, causant à Mallory une perte d’argent sur les frais alors que Bob confirme l’état final pour le même coût de frais qu’il était déjà prêt à payer. Cependant, si Mallory peut répétitivement empêcher Bob d’être informé sur ses diffusions d’anciens états avant qu’ils ne soient confirmés, elle peut l’empêcher de répondre jusqu’à ce que les HTLCs dans le canal expirent et qu’elle soit en mesure de voler des fonds.

  Roberts a proposé un schéma qui permet à un participant de canal de confirmer seulement un seul état. Si un état ultérieur est confirmé, le participant qui a soumis l’état final et tout participant qui n’a soumis aucun état peuvent prendre l’argent de tout participant qui a soumis des états périmés.

  Malheureusement, après avoir publié le schéma, Roberts a découvert et auto-divulgué un défaut critique dans celui-ci : similaire au problème de retard 2x décrit dans le paragraphe précédent, le dernier parti à signer peut compléter un état qu’aucune autre partie ne peut compléter, donnant au signataire final un accès exclusif à l’état final actuel. Si une autre partie tente de clôturer dans l’état précédent, elle perdra de l’argent si le signataire final utilise l’état final.

  Roberts étudie des approches alternatives, mais le sujet a suscité une discussion intéressante sur l’utilité ou non d’ajouter un mécanisme de pénalité à LN-Symmetry. Gregory Sanders, dont la mise en œuvre antérieure de preuve de concept de LN-Symmetry l’a amené à croire qu’un mécanisme de pénalité est inutile (voir le Bulletin #284), a noté que l’attaque par répétition de l’ancien état est similaire à une attaque par remplacement cyclique. Il trouve “cette attaque assez faible, puisque l’attaquant peut être amené à une EV [valeur attendue] négative assez facilement” même si le défenseur dispose de ressources modestes et n’a aucune idée des transactions que les mineurs tentent de confirmer.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles versions ou d’aider à tester les versions candidates.

• ● Bitcoin Core 28.1 est une version de maintenance de l’implémentation de nœud complet prédominante.

• ● BDK 0.30.1 est une version de maintenance pour la série de versions précédente contenant des corrections de bugs. Les projets sont encouragés à passer à BDK wallet 1.0.0, comme annoncé dans le bulletin de la semaine dernière, pour laquelle un guide de migration a été fourni.

• ● LDK v0.1.0-beta1 est un candidat à la sortie de cette bibliothèque pour la construction de portefeuilles et d’applications activés par LN.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

• ● Bitcoin Core #28121 ajoute un nouveau champ reject-details à la réponse de la commande RPC testmempoolaccept, qui est inclus uniquement si la transaction était rejetée du mempool en raison de violations de consensus ou de politique. Le message d’erreur est identique à celui renvoyé par sendrawtransaction si la transaction y était également rejetée.

• ● BDK #1592 introduit des Architectural Decision Records (ADRs) pour documenter les changements significatifs, en décrivant le problème abordé, les moteurs de décision, les alternatives considérées, les avantages et les inconvénients, et la décision finale. Cela permet aux nouveaux venus de se familiariser avec l’historique du référentiel. Cette PR ajoute un modèle d’ADR et les deux premiers ADRs : l’un pour supprimer le module persist de bdk_chain et l’autre pour introduire un nouveau type PersistedWallet qui enveloppe un BDKWallet.