Le bulletin de cette semaine fait suite à plusieurs discussions récentes sur les modifications proposées au langage de script de Bitcoin. Elle comprend également nos sections habituelles annonçant les nouvelles versions et décrivant les changements importants apportés aux logiciels d’infrastructure Bitcoin les plus populaires.

Nouvelles

  • ● Poursuite des discussions sur les modifications de script : plusieurs réponses ont été publiées sur la liste de diffusion Bitcoin-Dev concernant les discussions que nous avons précédemment couvertes.

    • ● Recherche sur les covenants : Anthony Towns a répondu à un message de Rusty Russell que nous avons mentionné la semaine dernière. Towns compare l’approche de Russell à d’autres approches spécifiquement pour les coffre-forts basés sur des covenants et la trouve peu attrayante. Dans une réponse ultérieure, Russell note qu’il existe différents designs pour les coffre-forts et que ceux-ci sont fondamentalement moins optimaux que d’autres types de transactions, ce qui implique que l’optimisation n’est pas essentielle pour les utilisateurs de coffre-forts. Il soutient que l’approche des coffre-forts du BIP345 est plus adaptée à un format d’adresse qu’à un ensemble d’opcodes, ce qui signifie que le BIP345 a plus de sens en tant que modèle (comme P2WPKH) conçu pour une fonction spécifique plutôt qu’en tant qu’ensemble d’opcodes conçus pour cette fonction spécifique mais qui pourraient interagir de manière imprévue avec le reste du script.

      Towns examine également l’utilisation de l’approche de Russell dans le but de permettre en général l’expérimentation et la trouve “plus intéressante […] mais encore assez limitée”. Il rappelle aux lecteurs sa proposition précédente de fournir une alternative de style Lisp à Bitcoin Script (voir Newsletter #191) et montre comment cela pourrait apporter une flexibilité accrue et la possibilité d’effectuer une introspection des transactions lors de l’évaluation des témoins. Il fournit des liens vers son code de test et mentionne quelques exemples de jouets qu’il a écrits. Russell répond : “Je pense toujours qu’il y a beaucoup de place pour l’amélioration avant un remplacement. Il est difficile de comparer le [S]cript actuel avec une alternative, car la plupart des cas intéressants sont impossibles.”

      Towns et Russell discutent également brièvement de OP_CHECKSIGFROMSTACK, en particulier de sa capacité à permettre à des données authentifiées provenant d’un oracle d’être placées directement sur une pile d’évaluation.

    • ● Proposition OP_CAT : plusieurs personnes ont répondu au message d’Ethan Heilman annonçant une proposition de BIP pour OP_CAT, que nous avons également mentionnée la semaine dernière.

      Après que plusieurs réponses aient exprimé des inquiétudes quant à savoir si OP_CAT serait excessivement limité par la limite de 520 octets sur la taille des éléments de la pile, Peter Todd a décrit une façon d’augmenter cette limite dans une future mise à jour logicielle sans utiliser d’opcodes supplémentaires OP_SUCCESSx. L’inconvénient est que toutes les utilisations de OP_CAT avant cette augmentation nécessiteraient l’inclusion d’un petit nombre d’opcodes déjà disponibles supplémentaires dans leurs scripts.

      Dans un article publié avant la réponse similaire d’Anthony Towns à la recherche de Russell sur les covenants, James O’Beirne souligne les limitations significatives de l’utilisation de OP_CAT pour implémenter des coffres-forts. Il note spécifiquement plusieurs fonctionnalités que les versions OP_CAT n’ont pas par rapport aux coffres-forts de style BIP345.

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.118 est la dernière version de cette bibliothèque pour la construction d’applications compatibles LN. Elle inclut un support expérimental partiel pour le protocole offers, ainsi que d’autres nouvelles fonctionnalités et corrections de bugs.

  • ● Rust Bitcoin 0.31.1 est la dernière version de cette bibliothèque pour travailler avec les données Bitcoin. Consultez ses notes de version pour une liste des nouvelles fonctionnalités et corrections de bugs.

Remarque: Bitcoin Core 26.0rc1, mentionné dans notre dernière newsletter, est étiqueté mais les binaires n’ont pas été téléchargés en raison d’un changement d’Apple qui a empêché la création de binaires reproductibles pour macOS. Les développeurs de Bitcoin Core travaillent sur une solution pour un deuxième candidat à la version.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #28685 corrige un bug dans le calcul du hachage d’un ensemble de UTXO, mentionné dans une newsletter précédente. Il inclut un changement incompatible avec la version précédente de l’API gettxoutsetinfo, remplaçant la valeur précédente hash_serialized_2 par hash_serialized_3, contenant le hachage corrigé.

  • ● Bitcoin Core #28651 permet à miniscript d’estimer plus précisément le nombre maximal d’octets qui devront être inclus dans la structure de témoin pour dépenser une sortie taproot. Cette amélioration de précision aidera le portefeuille de Bitcoin Core à éviter de payer des frais excessifs.

  • ● Bitcoin Core #28565 s’appuie sur #27511 pour ajouter une API getaddrmaninfo qui expose les comptes des adresses de pairs qui sont soit “nouvelles” soit “essayées”, segmentées par réseau (IPv4, IPv6, Tor, I2P, CJDNS). Voir Newsletter #237 et le Podcast #237 pour plus d’informations concernant la motivation derrière cette segmentation.

  • ● LND #7828 commence à exiger que les pairs répondent à ses messages de protocole LN ping dans un délai raisonnable, sinon ils seront déconnectés. Cela permet de garantir que les connexions restent actives (réduisant ainsi les chances qu’une connexion morte bloque un paiement et déclenche une fermeture forcée de canal non désirée). Il y a de nombreux avantages supplémentaires aux pings et pongs LN : ils peuvent aider à dissimuler le trafic réseau, rendant ainsi plus difficile le suivi des paiements par un observateur du réseau (car les paiements, les pings et les pongs sont tous chiffrés) ; ils déclenchent des rotations plus fréquentes des clés de chiffrement, comme décrit dans BOLT1 ; et LND utilise en particulier les messages pong pour aider à prévenir les attaques par éclipse (voir Newsletter #164).

  • ● LDK #2660 donne aux appelants plus de flexibilité sur les frais qu’ils peuvent choisir pour les transactions onchain, y compris des paramètres pour payer le minimum absolu, un taux bas qui peut prendre plus d’un jour pour être confirmé, une priorité normale et une priorité élevée.

  • ● BOLTs #1086 spécifie que les nœuds doivent rejeter (rembourser) un HTLC et renvoyer une erreur expiry_too_far si les instructions pour créer une demande de HTLC transmise demandent au nœud local d’attendre plus de 2 016 blocs avant de pouvoir réclamer un remboursement. La réduction de ce paramètre réduit la perte maximale de revenus pour un nœud provenant d’une attaque de congestion de canal particulière ou de factures en attente de longue date. L’augmentation de ce paramètre permet de faire transiter les paiements sur plus de canaux pour le même paramètre de variation HTLC maximal (ou le même nombre de sauts pour un paramètre de variation HTLC maximal plus élevé, ce qui peut améliorer la résistance à certaines attaques, telles que l’attaque de remplacement cyclique décrite dans le bulletin de la semaine dernière).