Le septième numéro spécial annuel de rétrospective de Bitcoin Optech résume les développements notables dans Bitcoin durant toute l’année 2024. C’est la suite de nos résumés de 2018, 2019, 2020, 2021, 2022, et 2023.

Sommaire

Janvier

John Law a proposé des timelocks dépendants des frais, un soft fork permettant aux timelocks d’expirer uniquement lorsque les taux de frais médians des blocs tombent en dessous d’un niveau spécifié par l’utilisateur. Cela empêche les frais élevés près de l’expiration d’empêcher la confirmation, ce qui peut entraîner une perte de fonds. Au lieu de cela, le timelock se prolonge jusqu’à ce que les frais tombent à une valeur prédéterminée, répondant aux préoccupations de longue date concernant les inondations d’expiration forcées lors de fermetures massives de canaux. La proposition améliore la sécurité pour les configurations multi-utilisateurs comme les channel factories et les joinpools tout en incitant les participants à éviter les pics de frais. Les discussions ont également porté sur le stockage des paramètres dans l’annexe taproot, les engagements de taux de frais pour les clients légers, la prise en charge des nœuds élagués, et l’impact des frais hors bande.

Salvatore Ingala a proposé une méthode pour optimiser les sorties des contrats multipartite, comme les joinpools ou les channel factories, en permettant aux utilisateurs de coordonner une seule transaction au lieu de diffuser des transactions séparées. Cela réduit la taille onchain d’au moins 50% et jusqu’à 99% dans des circonstances idéales, ce qui est crucial lorsque les frais sont élevés. Un mécanisme de caution assure l’exécution honnête : un participant construit la transaction mais perd la caution s’il est prouvé qu’il fraude. Ingala suggère d’implémenter cela avec les fonctionnalités de soft fork OP_CAT et MATT, avec une efficacité supplémentaire possible en utilisant OP_CSFS et l’arithmétique 64 bits.

Gregory Sanders a partagé une preuve de concept d’implémentation de LN-Symmetry en utilisant un fork de Core Lightning. LN-Symmetry permet des canaux de paiement bidirectionnels sans transactions de pénalité mais repose sur un soft fork comme SIGHASH_ANYPREVOUT pour permettre aux transactions enfants de dépenser n’importe quelle version parente. Sanders a souligné sa simplicité par rapport à LN-Penalty, la difficulté d’éviter l’épinglage (inspirant son travail sur le relais de paquets et les ancres éphémères), et le potentiel de paiements plus rapides via l’émulation de OP_CTV. Il a confirmé que les pénalités sont inutiles, simplifiant l’implémentation des canaux et évitant les fonds réservés. Cependant, LN-Symmetry nécessite des deltas d’expiration CLTV plus longs pour prévenir les abus.

Février

Peter Todd a proposé Remplacement par Taux de Frais (RBFr) pour adresser l’épinglage de transaction lorsque les politiques standard de RBF échouent, avec deux variantes : RBFr pur, permettant des remplacements illimités avec des taux de frais beaucoup plus élevés (par exemple, 2x), et one-shot RBF, permettant un remplacement unique avec des frais modérément plus élevés (par exemple, 1,25x) si le remplacement atteint le haut du mempool. Mark Erhardt a identifié un problème initial et d’autres développeurs ont discuté des complexités d’analyser complètement l’idée avec les outils disponibles. Todd a publié une implémentation expérimentale et d’autres développeurs ont continué à travailler sur des solutions alternatives pour aborder le problème d’épinglage de transactions, y compris le développement des outils nécessaires pour augmenter la confiance dans toute solution adoptée.

Matt Corallo a proposé un BIP pour des instructions de paiement Bitcoin lisibles par l’homme basées sur DNS news290 dns, permettant à une chaîne de type email (par exemple, exemple@exemple.com) de résoudre vers un enregistrement TXT signé DNSSEC contenant une URI BIP21. Cela prend en charge les adresses onchain, les paiements silencieux, et les offres LN—et peut être facilement étendu à d’autres protocoles de paiement. Une spécification de cela a été ajoutée comme BIP353. Corallo a également rédigé un BOLT et un BLIP pour les nœuds LN, permettant les enregistrements DNS génériques et la résolution de paiement sécurisée en utilisant des offres. Une implémentation a été fusionnée dans LDK en novembre. Le développement de ce protocole et des paiements silencieux a conduit Josie Baker à lancer une discussion sur la révision des URI de paiement BIP21, qui a continué plus tard dans l’année.

Fabian Jahr a écrit un logiciel qui permet à plusieurs développeurs de créer de manière indépendante des ASMaps équivalents, ce qui aide Bitcoin Core à diversifier les connexions entre pairs et à résister aux attaques par éclipse. Si l’outil de Jahr devient largement accepté, Bitcoin Core pourrait inclure les ASMaps par défaut, améliorant la protection contre les attaques de parties contrôlant des nœuds sur plusieurs sous-réseaux.

La prise en charge du double financement a été ajoutée à la spécification LN ainsi que celle du protocole de construction de transaction interactive. La construction interactive permet à deux nœuds d’échanger des préférences et des détails d’UTXO qu’ils peuvent utiliser pour construire ensemble une transaction de financement. Le financement double permet à une transaction d’inclure des entrées de l’une ou des deux parties. Par exemple, Alice peut vouloir ouvrir un canal avec Bob. Avant ce changement de spécification, Alice devait fournir tout le financement pour le canal. Maintenant, en utilisant une implémentation qui prend en charge le financement double, Alice peut ouvrir un canal avec Bob où il fournit tout le financement ou bien où chacun contribue à l’état initial du canal. Cela peut être combiné avec le protocole expérimental des annonces de liquidité, qui n’a pas encore été ajouté à la spécification.

ZmnSCPxj a proposé des scripts sans confiance permettant à deux parties de parier sur les futurs taux de frais de bloc. Un utilisateur souhaitant qu’une transaction soit confirmée par un futur bloc peut utiliser cela pour compenser le risque que les taux de frais soient inhabituellement élevés à ce moment-là. Un mineur s’attendant à miner un bloc au moment où l’utilisateur a besoin que sa transaction soit confirmée peut utiliser ce contrat pour compenser le risque que les taux de frais soient inhabituellement bas. La conception empêche la manipulation observée dans les marchés centralisés, car les décisions du mineur reposent uniquement sur les conditions réelles du minage. Le contrat est sans confiance avec un chemin de dépense coopératif qui minimise les coûts pour les deux parties.

Résumé 2024 : Divulgations de vulnérabilités

En 2024, Optech a résumé plus de deux douzaines de divulgations de vulnérabilités. La majorité étaient d’anciennes divulgations de Bitcoin Core qui étaient publiées pour la première fois cette année. Les rapports de vulnérabilité donnent aux développeurs et aux utilisateurs l’opportunité d’apprendre des problèmes passés, et les divulgations responsables nous permettent à tous de remercier ceux qui rapportent leurs découvertes avec discrétion.

Note : Optech ne publie les noms des découvreurs de vulnérabilités que si nous pensons qu’ils ont fait un effort raisonnable pour minimiser le risque de préjudice pour les utilisateurs. Nous remercions toutes les personnes nommées dans cette section pour leur perspicacité et leur préoccupation claire pour la sécurité des utilisateurs.

Fin 2023, Niklas Gögge a divulgué publiquement deux vulnérabilités qu’il avait signalées deux ans plus tôt, conduisant à la sortie de versions corrigées de LND. La première, une vulnérabilité de DoS, aurait pu entraîner un manque de mémoire et un crash de LND. La seconde, une vulnérabilité de censure, pourrait permettre à un attaquant d’empêcher un nœud LND d’être informé des mises à jour des canaux ciblés à travers le réseau ; un attaquant pourrait utiliser cela pour inciter malicieusement un nœud à sélectionner des itinéraires spécifiques pour les paiements qu’il envoie, donnant à l’attaquant plus de frais de transfert et plus d’informations sur les paiements envoyés par le nœud.

En janvier, Matt Morehouse a annoncé une vulnérabilité qui affectait les versions de Core Lightning de 23.02 à 23.05.2. Lors du re-test de nœuds qui avaient implémenté des corrections pour le financement fictif, qu’il avait précédemment découvert et divulgué, il a pu déclencher une condition de concurrence qui faisait planter CLN après environ 30 secondes. Si un nœud LN est arrêté, il ne peut pas défendre un utilisateur contre des contreparties malveillantes ou défectueuses, ce qui met les fonds de l’utilisateur en danger.

Également en janvier, Gögge est revenu pour annoncer une vulnérabilité de défaillance de consensus qu’il a trouvée dans le nœud complet btcd. Le code pourrait mal interpréter un numéro de version de transaction et appliquer les mauvaises règles de consensus à une transaction utilisant un verrouillage temporel relatif. Cela pourrait empêcher les nœuds complets btcd d’afficher les mêmes transactions confirmées que Bitcoin Core, mettant les utilisateurs en risque de perdre de l’argent.

Février a vu Eugene Siegel publier un rapport de vulnérabilité de Bitcoin Core qu’il avait initialement divulgué presque trois ans auparavant. La vulnérabilité pourrait être utilisée pour empêcher Bitcoin Core de télécharger des blocs récents. Cela pourrait être utilisé pour empêcher un nœud LN connecté d’apprendre les préimages nécessaires pour résoudre les HTLCs, potentiellement conduisant à une perte d’argent.

Morehouse est revenu en juin pour divulguer une vulnérabilité permettant de faire planter des versions de LND avant 0.17.0. Comme mentionné précédemment, un nœud LN arrêté ne peut pas défendre un utilisateur contre des contreparties malveillantes ou défectueuses, ce qui met les fonds de l’utilisateur en danger.

Juillet a vu la première des multiples divulgations de vulnérabilités affectant des versions passées de Bitcoin Core. Wladimir J. Van Der Laan enquêtait sur une vulnérabilité découverte par Aleksandar Nikolic dans une bibliothèque utilisée par Bitcoin Core lorsqu’il a découvert une vulnérabilité séparée permettant l’exécution de code à distance ; cela a été corrigé en amont, et la correction a été intégrée dans Bitcoin Core. Le développeur Evil-Knievel a découvert une vulnérabilité qui pourrait épuiser la mémoire de nombreux nœuds Bitcoin Core, les faisant planter, ce qui pourrait être utilisé dans le cadre d’autres attaques pour voler de l’argent (par exemple, des utilisateurs de LN). John Newbery, citant la co-découverte par Amiti Uttarwar, a révélé une vulnérabilité qui pourrait être utilisée pour censurer des transactions non confirmées, ce qui pourrait également être utilisé dans le cadre d’attaques pour voler de l’argent (encore une fois, un cas d’exemple étant celui des utilisateurs de LN). Une vulnérabilité a été signalée permettant de consommer une quantité excessive de CPU et de mémoire, pouvant potentiellement conduire à un crash du nœud. Le développeur practicalswift a découvert une vulnérabilité qui pourrait amener un nœud à ignorer des blocs légitimes pendant un certain temps, retardant la réaction à des événements sensibles au temps qui pourraient affecter les protocoles de contrat comme LN. Le développeur sec.eine a révélé une vulnérabilité qui pourrait consommer une quantité excessive de CPU, ce qui pourrait être utilisé pour empêcher un nœud de traiter de nouveaux blocs et transactions, pouvant potentiellement conduire à de multiples problèmes pouvant entraîner une perte d’argent. John Newbery a divulgué de manière responsable une autre vulnérabilité qui pourrait épuiser la mémoire de nombreux nœuds, pouvant potentiellement conduire à des crashs. Cory Fields a découvert une vulnérabilité distincte d’épuisement de la mémoire qui pourrait faire planter Bitcoin Core. John Newbery a révélé une troisième vulnérabilité qui pourrait gaspiller la bande passante et limiter le nombre de slots de connexion de pairs d’un utilisateur. Michael Ford a signalé une vulnérabilité d’épuisement de la mémoire affectant quiconque cliquait sur une URL BIP72, ce qui pourrait faire planter un nœud.

D’autres révélations de la part de Bitcoin Core ont suivi dans les mois suivants. Eugene Siegel a découvert une méthode pour faire planter Bitcoin Core en utilisant des messages addr. Michael Ford, enquêtant sur un rapport de Ronald Huveneers concernant la bibliothèque miniupnpc, a découvert une méthode différente pour faire planter Bitcoin Core en utilisant des connexions réseau locales. David Jaenson, Braydon Fuller et plusieurs développeurs de Bitcoin Core ont découvert une vulnérabilité qui pourrait être utilisée pour empêcher un nœud complet nouvellement démarré de se synchroniser avec la meilleure chaîne de blocs ; la vulnérabilité a été éliminée avec un correctif de bug post-fusion par Niklas Gögge. Une autre vulnérabilité de crash à distance a été découverte par Niklas Gögge, exploitant un problème avec la gestion des messages de blocs compacts. Plusieurs utilisateurs ont signalé une consommation excessive de CPU, amenant les développeurs 0xB10C et Anthony Towns à enquêter sur la cause et à mettre en œuvre une solution. Plusieurs développeurs, dont William Casarin et ghost43, ont signalé des problèmes avec leurs nœuds, conduisant Suhas Daftuar à isoler une vulnérabilité qui pourrait empêcher Bitcoin Core d’accepter un bloc pendant longtemps. Le dernier rapport de vulnérabilité de Bitcoin Core rapporté cette année décrivait une méthode pour retarder les blocs de 10 minutes ou plus.

Lloyd Fournier, Nick Farrow et Robin Linus ont annoncé Dark Skippy, une méthode améliorée pour l’exfiltration de clés à partir d’un dispositif de signature Bitcoin qu’ils avaient précédemment divulguée de manière responsable à environ 15 différents fournisseurs de dispositifs de signature matérielle. L’exfiltration survient lorsque le code de signature de transaction crée délibérément ses signatures de manière à ce qu’elles divulguent des informations sur le matériel clé sous-jacent, tel qu’une clé privée ou une graine de portefeuille HD BIP32. Une fois qu’un attaquant obtient la graine d’un utilisateur, il peut voler tous les fonds de l’utilisateur à tout moment (y compris les fonds dépensés dans la transaction qui résulte en exfiltration, si l’attaquant agit rapidement). Cela a conduit à une discussion renouvelée sur les protocoles de signature anti-exfiltration.

L’introduction d’un nouveau testnet a également vu la découverte d’une nouvelle vulnérabilité de timewarp. Testnet4 incluait un correctif pour la vulnérabilité originale de timewarp, mais le développeur Zawy a découvert en août un nouvel exploit qui pourrait réduire la difficulté d’environ 94%. Mark “Murch” Erhardt a développé davantage l’attaque pour permettre de réduire la difficulté à sa valeur minimale. Plusieurs solutions ont été proposées et les compromis entre elles étaient encore en discussion en décembre.

Illustration de la nouvelle vulnérabilité timewarp

En octobre, Antoine Poinsot et Niklas Gögge ont révélé une autre vulnérabilité de défaillance de consensus affectant le nœud complet btcd. Depuis la version originale de Bitcoin, elle a contenu une fonction obscure (mais critique) utilisée pour extraire les signatures des scripts avant de les hacher. L’implémentation dans btcd différait légèrement de la version originale héritée par Bitcoin Core, permettant à un attaquant de créer des transactions qui seraient acceptées par un nœud mais rejetées par l’autre, ce qui pourrait être utilisé de diverses manières pour faire perdre de l’argent aux utilisateurs.

Décembre a vu David Harding révéler une vulnérabilité affectant Eclair, LDK, et LND par défaut (et Core Lightning avec des paramètres non par défaut). La partie qui a demandé à ouvrir un canal (l’initiateur) et qui était responsable du paiement de tous les frais endogènes nécessaires pour fermer le canal pouvait s’engager à payer 98% de la valeur du canal en frais dans un état, réduire l’engagement à un montant minimal dans un état ultérieur, transférer 99% de la valeur du canal à l’autre partie, puis fermer le canal dans l’état à 98% de frais. Cela résulterait dans le fait que l’initiateur perd 1% de la valeur du canal pour avoir utilisé un ancien état mais l’autre partie perdrait 98% de la valeur du canal. Si l’initiateur minait la transaction lui-même, il pourrait conserver les 98% de la valeur du canal payés en frais. Cette méthode permettrait de voler environ 3 000 canaux par bloc.

Une vulnérabilité de déanonymisation affectant Wasabi et les logiciels associés a été la dernière divulgation résumée par Optech cette année. La vulnérabilité permet à un coordinateur de coinjoin du type utilisé par Wasabi et GingerWallet de fournir aux utilisateurs des identifiants censés être anonymes mais qui peuvent être rendus distincts pour permettre le suivi. Bien qu’une méthode de rendu des identifiants distincts ait été éliminée, un problème plus généralisé permettant à un coordinateur de produire des identifiants distincts a été identifié en 2021 par Yuval Kogman et reste non résolu à ce jour.

Mars

Les problèmes continus pour intégrer les BIPs ont conduit à la création en janvier d’un nouveau dépôt BINANA pour les spécifications et autres documentations. Février et mars ont vu l’éditeur actuel des BIPs demander de l’aide et le début d’un processus pour ajouter de nouveaux éditeurs. Après une discussion publique approfondie culminant en avril, plusieurs contributeurs de Bitcoin ont été nommés éditeurs de BIPs.

Abubakar Sadiq Ismail a proposé d’améliorer l’estimation du taux de frais de Bitcoin Core en utilisant les données en temps réel du mempool. Actuellement, les estimations se basent sur les données des transactions confirmées, qui se mettent à jour lentement mais résistent à la manipulation. Ismail a développé un code préliminaire comparant l’approche actuelle avec un nouvel algorithme basé sur le mempool. Les discussions ont souligné si les données du mempool devraient ajuster les estimations à la hausse et à la baisse, ou seulement les diminuer. L’ajustement double améliore l’utilité, mais limiter les ajustements à la baisse des estimations peut mieux prévenir la manipulation.

Martin Habovštiak a proposé une méthode pour augmenter les priorités des transactions non liées en utilisant l’annexe taproot, réduisant considérablement les besoins en espace par rapport aux méthodes antérieures de parrainage de frais. David Harding a suggéré une approche encore plus efficace utilisant des messages d’engagement de signature, ne nécessitant aucun espace onchain mais dépendant de l’ordre des blocs. Pour les transactions de parrainage qui se chevauchent, Harding et Anthony Towns ont proposé des alternatives utilisant aussi peu que 0,5 vbytes par augmentation. Towns a noté que ces méthodes de parrainage sont compatibles avec le design proposé du mempool en cluster, bien que les versions les plus efficaces présentent de légers défis pour la mise en cache de la validité des transactions en rendant plus difficile pour les nœuds de précalculer et de stocker les informations de validité. Cette approche de parrainage permet une augmentation dynamique des frais à un coût minimal, la rendant attrayante pour les protocoles nécessitant des frais exogènes, bien que la sous-traitance sans confiance reste un problème. Suhas Daftuar a averti que le parrainage pourrait créer des problèmes pour les utilisateurs non participants, suggérant qu’il soit opt-in s’il est adopté pour éviter des impacts non intentionnés.

Avril

Antoine Poinsot a réexaminé la proposition de nettoyage du consensus de Matt Corallo de 2019, abordant des problèmes tels que la vérification lente des blocs, les attaques de manipulation temporelle permettant le vol, et les vulnérabilités de transactions factices affectant les clients légers et les nœuds complets. Poinsot a également souligné le problème des transactions en double qui affectera les nœuds complets au bloc 1,983,702. Tous les problèmes ont des solutions de soft-fork, bien qu’une solution proposée pour les blocs à vérification lente ait soulevé des préoccupations quant à l’invalidation potentielle de transactions pré-signées rares. L’une des mises à jour proposées a reçu une discussion significative en août et septembre examinant des méthodes alternatives pour atténuer les vulnérabilités des arbres de Merkle qui affectent les clients légers et même (parfois) les nœuds complets. Bien que Bitcoin Core ait atténué les vulnérabilités autant que possible, une refactorisation précédente a supprimé des protections essentielles, donc Niklas Gögge a écrit du code pour Bitcoin Core qui détecte toutes les vulnérabilités actuellement détectables le plus tôt possible et rejette les blocs invalides. En décembre, la discussion s’est orientée vers l’utilisation du soft fork de nettoyage du consensus pour corriger la variante Zawy-Murch de la vulnérabilité du décalage temporel qui a été découverte après l’implémentation sur testnet4 des règles conçues pour la proposition originale de nettoyage du consensus.

Un dérivé de la discussion sur l’ajout d’un nouvel éditeur de BIPs a manifesté le désir de réformer le BIP2, qui spécifie le processus actuel pour ajouter de nouveaux BIPs et mettre à jour les BIPs existants. La discussion a continué le mois suivant, et septembre a vu la publication d’un brouillon de BIP pour une mise à jour du processus.

LND a introduit la prise en charge des frais de routage entrants, promu par Joost Jager, qui permet aux nœuds de facturer des frais spécifiques au canal pour les paiements reçus de pairs. Cela aide les nœuds à gérer la liquidité, comme facturer des frais plus élevés pour les paiements entrants de nœuds mal gérés. Les frais entrants sont compatibles avec les versions antérieures, initialement fixés à négatif (par exemple, des réductions) pour fonctionner avec les anciens nœuds. Bien que proposée il y a des années, d’autres implémentations de LN n’ont pas intégré la fonctionnalité, invoquant des problèmes de conception et de compatibilité. La fonctionnalité a vu un développement continu dans LND tout au long de l’année.

Greg Sanders a proposé l’utilisation de blocs faibles—des blocs avec une preuve de travail (PoW) insuffisante mais des transactions valides—pour améliorer le relais de blocs compacts face à des politiques divergentes de relais de transactions et de minage. Les mineurs produisent naturellement des blocs faibles proportionnellement à leur pourcentage de PoW, reflétant les transactions qu’ils tentent de miner. Les blocs faibles résistent aux abus en raison de coûts de création élevés, permettant aux mempools et aux caches d’être mis à jour sans permettre un gaspillage excessif de bande passante. Cela pourrait garantir que le relais de blocs compacts reste efficace même lorsque les mineurs incluent des transactions non standard dans les blocs. Les blocs faibles pourraient également aborder les attaques d’épinglage et améliorer l’estimation du taux de frais. L’implémentation de preuve de concept de Sanders démontre l’idée.

Jameson Lopp a commencé une discussion en avril sur les problèmes avec le testnet public actuel de Bitcoin (testnet3) et a suggéré de le redémarrer, potentiellement avec un ensemble différent de règles de consensus spéciales. En mai, Fabian Jahr a annoncé un brouillon de BIP et une proposition d’implémentation pour testnet4. Le BIP et l’implémentation de Bitcoin Core ont été fusionnés en août.

Avril s’est terminé de manière malheureuse avec la nouvelle de l’arrestation de deux développeurs de Bitcoin axés sur le logiciel de confidentialité, ainsi qu’au moins deux autres entreprises annonçant leur intention de cesser de servir les clients américains en raison des risques juridiques.

Résumé 2024 : Cluster mempool

L’idée (de 2023 ) de refondre le mempool est devenue un point d’attention particulier pour plusieurs développeurs de Bitcoin Core tout au long de 2024. Le cluster mempool rend beaucoup plus facile de raisonner sur l’effet des transactions sur tous les blocs qu’un mineur créerait s’il possède un mempool identique à celui du nœud local. Cela peut rendre l’éviction des transactions plus rationnelle et aider à déterminer si une transaction de remplacement (ou un ensemble de transactions) est meilleure que les transactions qu’elle remplace. Cela peut aider à aborder diverses limitations du mempool qui sont impliquées dans de multiples problèmes affectant les protocoles de contrat tels que LN (y compris parfois la mise en danger des fonds).

De plus, comme vu dans un post de janvier par Abubakar Sadiq Ismail, les outils et les insights issus de la conception du cluster mempool peuvent permettre d’améliorer l’estimation des frais dans Bitcoin Core. Aujourd’hui, Bitcoin Core implémente l’exploitation de la feerate ancestrale comme une manière compatible avec les incitations pour soutenir le bumping de frais CPFP, mais l’estimation des frais opère sur des transactions individuelles, donc les bumps de frais CPFP ne sont pas considérés. Le cluster mempool divise les groupes de transactions en blocs qui peuvent être suivis ensemble dans le mempool puis potentiellement localisés dans des blocs minés, permettant une meilleure estimation des frais (surtout s’il y a une utilisation accrue de technologies liées au CPFP comme le relais de paquets, P2A, et la source de frais exogène.

À mesure que le projet de mempool en cluster mûrissait, plusieurs explications et aperçus ont été faits par ses architectes. Suhas Daftuar a donné un aperçu en janvier, qui a révélé l’un des défis de la proposition : son incompatibilité avec la politique existante de carve-out CPFP. Une solution au dilemme serait que les utilisateurs existants de carve-out optent pour les transactions TRUC, qui fournissent un ensemble de fonctionnalités améliorées. Une autre description détaillée du cluster mempool a été postée en juillet par Pieter Wuille. Elle décrivait les principes fondamentaux, les algorithmes proposés, et renvoyait à plusieurs pull requests. Plusieurs de ces pull requests et d’autres ont par la suite été fusionnés.

Daftuar a poursuivi sa réflexion et sa recherche derrière le cluster mempool et des propositions connexes comme les transactions TRUC. En février, il a considéré la compatibilité des incitations d’idées telles que le remplacement par feerate, les incitations différentes des mineurs avec des quantités disproportionnées de hashrate, et recherché un comportement compatible avec les incitations qui n’était pas résistant aux DoS. En avril, il a recherché ce qui se serait passé si le cluster mempool avait été déployé un an plus tôt, découvrant que cela permettait légèrement plus de transactions dans le mempool, n’affectait pas significativement le remplacement des transactions dans les données, et pourrait aider les mineurs à capturer plus de frais à court terme. Pieter Wuille a développé le dernier point en août en décrivant les principes et un algorithme efficace pour une sélection de transactions presque optimale pour les mineurs construisant des blocs.

Mai

Le travail a continué cette année sur le rendu des paiements silencieux plus largement accessibles. Josie Baker a commencé une discussion sur les extensions PSBT pour les paiements silencieux (SPs), basée sur un brouillon de spécification par Andrew Toth. Cette discussion s’est poursuivie en juin avec un examen de l’utilisation de parts ECDH pour une coordination sans confiance. Séparément, Setor Blagogee a posté un brouillon de spécification pour un protocole visant à aider les clients légers à recevoir des paiements silencieux. Quelques ajustements ont été apportés à la spécification de base SP en juin et deux projets de BIPs pour les fonctionnalités PSBT proposées ont été publiés.

Sergio Demian Lerner et plusieurs co-auteurs ont publié un article sur une nouvelle architecture de CPU virtuel basée en partie sur les idées derrière BitVM. L’objectif de leur projet, BitVMX, est de pouvoir prouver efficacement la bonne exécution de tout programme qui peut être compilé pour fonctionner sur une architecture CPU établie, telle que RISC-V. Comme BitVM, BitVMX ne nécessite aucun changement de consensus, mais il exige qu’une ou plusieurs parties désignées agissent en tant que vérificateur de confiance. Cela signifie que plusieurs utilisateurs participant de manière interactive à un protocole de contrat peuvent empêcher l’une (ou plusieurs) des parties de retirer de l’argent du contrat à moins que cette partie n’exécute avec succès un programme arbitraire spécifié par le contrat.

Adam Gibson a décrit un schéma de jeton d’utilisation anonyme qu’il a développé pour permettre à quiconque pouvant dépenser un UTXO avec un chemin de clés de prouver qu’il pourrait le dépenser sans révéler de quel UTXO il s’agit. Une utilisation qu’il met en avant est de permettre l’annonce de canaux LN sans exiger que les propriétaires identifient les UTXOs spécifiques soutenant ces canaux, ce qui est nécessaire actuellement pour prévenir les attaques de déni de service qui gaspillent la bande passante. Gibson a également créé un forum de preuve de concept qui nécessite de fournir une preuve anonyme pour s’inscrire, créant un environnement où tout le monde est connu pour être détenteur de bitcoins mais personne n’a besoin de fournir aucune information d’identification sur eux-mêmes ou leurs bitcoins. Plus tard dans l’année, Johan Halseth a annoncé une implémentation de preuve de concept qui atteint la plupart des mêmes objectifs en utilisant un mécanisme différent.

Pendant des années, les développeurs de LN ont discuté de la modification du protocole LN pour permettre la mise à niveau des canaux existants de diverses manières. En mai, Carla Kirk-Cohen a examiné certains de ces cas et comparé trois propositions différentes pour les mises à niveau. Un protocole de quiescence a été ajouté à la spécification LN en juin pour aider à soutenir les mises à niveau et d’autres opérations sensibles. Octobre a vu le renouvellement du développement d’une proposition de protocole de mises à jour des annonces de canal qui prendrait en charge de nouvelles transactions de financement basées sur taproot.

Ethan Tuttle a posté sur Delving Bitcoin pour suggérer que les pools de minage pourraient récompenser les mineurs avec des jetons ecash proportionnellement au nombre de parts qu’ils ont minées. Les mineurs pourraient alors immédiatement vendre ou transférer les jetons, ou ils pourraient attendre que le pool mine un bloc, moment auquel le pool échangerait les jetons contre des satoshis. Cependant, Matt Corallo a soulevé une préoccupation : il n’existe pas de méthodes de paiement standardisées mises en œuvre par les grands pools qui permettent aux mineurs de pool de calculer combien ils sont censés être payés sur de courts intervalles. Cela signifie que les mineurs ne passeront pas rapidement à un autre pool si leur pool principal commence à les tromper sur les paiements, que ces paiements soient effectués avec ecash ou tout autre mécanisme.

Ava Chow a proposé un BIP pour miniscript en mai, qui est devenu le BIP379 en juillet.

Aussi en mai, une version bêta de utreexod a été publiée, permettant aux utilisateurs d’expérimenter avec cette conception de nœud complet qui minimise les exigences d’espace disque.

Juin

René Pickhardt a recherché comment estimer la probabilité de faisabilité d’un paiement LN en analysant les distributions de richesse possibles dans les capacités des canaux. Par exemple, si Alice veut envoyer 1 BTC à Carol via Bob, la probabilité de succès dépend si les canaux Alice-Bob et Bob-Carol peuvent prendre en charge le transfert. Cette métrique met en lumière les contraintes pratiques de paiement et pourrait aider les portefeuilles et les logiciels d’entreprise à prendre des décisions de routage plus intelligentes, améliorant ainsi les taux de succès pour les paiements LN. Plus tard dans l’année, la recherche de Pickhardt a fourni des aperçus sur la cause et la probabilité de l’épuisement des canaux—un canal devenant incapable de transférer des fonds dans une direction particulière. Elle a également indiqué que les protocoles de gestion de canaux multiparty avec k>2, tels que les [usines à canaux]]topic channel factories, pourraient grandement augmenter le nombre de paiements réalisables et réduire le taux d’épuisement des canaux.

Exemple d'épuisement de canal

Le développeur Hunter Beast a posté un “brouillon” de BIP pour attribuer des adresses segwit version 3 à un algorithme de signature résistant aux quantiques. Le brouillon de BIP décrit le problème et renvoie à plusieurs algorithmes potentiels ainsi qu’à leur taille attendue onchain. Le choix des algorithmes et les détails spécifiques de l’implémentation ont été laissés pour une discussion future.

Résumé 2024 : Relais de transaction P2P

La gestion des frais a toujours été un défi dans le protocole Bitcoin décentralisé, mais l’utilisation généralisée de protocoles contractuels tels que LN-Penalty et la recherche continue sur des protocoles plus nouveaux et plus complexes ont rendu plus important que jamais de s’assurer que les utilisateurs peuvent payer et augmenter les frais à la demande. Les contributeurs de Bitcoin Core travaillent sur ce problème depuis des années, et 2024 a vu la publication publique de plusieurs nouvelles fonctionnalités qui améliorent considérablement la situation.

Janvier a commencé avec une discussion sur les pires cas de coûts d’épinglage]topic transaction pinning pour la proposition TRUC qui offre une alternative plus robuste à la politique CPFP carve-out précédemment déployée. Bien que les pires cas de coûts soient beaucoup plus bas pour TRUC, les développeurs ont considéré qu’ajuster quelques paramètres pourrait être en mesure de réduire encore les coûts. Une autre discussion en janvier a examiné le risque théorique que l’utilisation accrue de la source de frais exogène rendrait plus efficace onchain (et donc moins cher) d’utiliser des paiements de frais hors bande aux mineurs, ce qui met en danger la décentralisation du minage. Peter Todd a suggéré de répondre à cette préoccupation avec une méthode de gestion des frais alternative : garder les frais entièrement endogènes en présignant plusieurs variations de chaque transaction de règlement à des taux de frais variables.Cependant, plusieurs problèmes ont été identifiés avec cette approche.

Une discussion supplémentaire en janvier par Gregory Sanders a examinée pour savoir s’il y avait un risque que le protocole LN insère des valeurs HTLC écourtées dans des sorties P2A, ce qui pourrait potentiellement permettre une valeur extractible par les mineurs (MEV) pour les mineurs qui exécutent un logiciel spécial au-delà de ce qui est nécessaire pour miner les transactions du mempool. Bastien Teinturier a lancé une discussion sur les changements nécessaires au protocole LN pour gérer les transactions d’engagement utilisant TRUC et les sorties P2A ; cela incluait la proposition de HTLC écourté considérée par Sanders, éliminant les délais d’un bloc désormais inutiles, et une réduction de la taille des transactions onchain. La discussion a également mené à une proposition TRUC enrichi qui appliquerait automatiquement les règles TRUC aux transactions ressemblant à l’utilisation existante de CPFP carve-out par LN, offrant les avantages de TRUC sans que le logiciel LN ait besoin d’être mis à jour.

Janvier s’est terminé avec une proposition de Gloria Zhao pour le remplacement par frais entre frères. Les règles RBF normales s’appliquent uniquement aux transactions conflictuelles où un nœud accepte juste une version de la transaction dans son mempool parce qu’une seule version est autorisée à exister dans une blockchain valide. Cependant, avec TRUC, un nœud accepte seulement un descendant d’une transaction parent non confirmée de version 3, une situation très similaire à une transaction conflictuelle. Permettre à un descendant de remplacer un autre descendant de la même transaction—c’est-à-dire l’éviction entre frères—améliorerait le bumping de frais des transactions TRUC et serait particulièrement bénéfique si TRUC enrichi est adopté.

Février a commencé avec des discussions supplémentaires sur les conséquences du passage du protocole LN de CPFP carve-out à TRUC. Matt Corallo a trouvé des défis à adapter les ouvertures de canaux zero-conf existantes à l’utilisation de TRUC en raison du fait que la transaction de financement et une transaction de fermeture immédiate pourraient être non confirmées, empêchant l’utilisation d’une troisième transaction contenant un bump de frais CPFP en raison de la limite de TRUC de deux transactions non confirmées. Teinturier a identifié un problème similaire si une chaîne de splices était utilisée. La discussion n’a jamais abouti à une conclusion claire, mais une solution de contournement consistant à s’assurer que chaque transaction contenait sa propre ancre pour le bumping de frais CPFP (comme requis avant TRUC) semblait satisfaisante, avec l’espoir que le mempool en cluster pourrait permettre d’assouplir certaines règles TRUC à l’avenir pour permettre un bumping de frais CPFP plus flexible.

Sur le sujet des changements de politique TRUC alimentés par les avancées du mempool en cluster, Gregory Sanders a décrit plusieurs idées pour des changements de politique futurs. En contraste, Suhas Daftuar a analysé toutes les transactions reçues par son nœud de l’année précédente pour voir comment une politique TRUC enrichie aurait affecté l’acceptation de ces transactions. La plupart des transactions précédemment acceptées sous la politique de CPFP carve-out auraient également été acceptées sous une politique TRUC enrichie, mais il y avait quelques exceptions qui pourraient nécessiter des changements de logiciel avant qu’une politique enrichie puisse être adoptée.

Après la vague de discussions en début d’année, mai et juin ont vu une Une série de fusions ajoutant la prise en charge de nouvelles fonctionnalités de relais à Bitcoin Core. Une forme limitée de relais de paquets un-parent-un-enfant (1p1c) ne nécessitant aucun changement au protocole P2P a été ajoutée. Un merge subséquent a augmenté la fiabilité du relais de paquets 1p1c en améliorant la gestion des transactions orphelines par Bitcoin Core. La spécification pour TRUC a été fusionnée dans le répertoire BIPs comme BIP431. Les transactions TRUC sont devenues relayables par défaut avec un autre merge. La prise en charge de RBF a également été ajouté pour le clusters 1p1c (incluant les paquets TRUC).

Deux développeurs de longue date ont écrit des critiques approfondies de TRUC en juillet, bien que d’autres développeurs aient répondu à leurs préoccupations. Une critique supplémentaire par les mêmes deux développeurs a été publiée en août.

Les développeurs de Bitcoin Core ont continué à travailler sur des améliorations de relais, en fusionnant la prise en charge des paiements vers des ancres éphémères (P2A) en août et en lançant Bitcoin Core 28.0 en octobre avec la prise en charge du relais de paquets 1p1c, le relais de transactions TRUC, le RBF de paquets et le remplacement de frères et sœurs, et un type de script de sortie P2A standard. Gregory Sanders, qui a contribué au développement de toutes ces fonctionnalités, a décrit comment les développeurs de portefeuilles et d’autres logiciels utilisant Bitcoin Core pour créer ou diffuser des transactions peuvent tirer parti des nouvelles capacités.

Plus tard dans l’année, la prise en charge des sorties de poussière éphémère utilisant P2A a été standardisé dans un merge. Cela permet à une transaction ne payant aucune frais d’être augmentée par une transaction enfant payant tous les frais pertinents—un type purement exogène de source de frais.

La dernière newsletter régulière de l’année d’Optech a résumé une réunion du Bitcoin Core Pull Request Review Club qui a discuté d’améliorations supplémentaires pour le relais de paquets 1p1c.

Juillet

Elle Mouton a proposé un BLIP pour ajouter un champ de chemin aveuglé aux factures BOLT11, permettant aux destinataires de paiement de cacher leur identité de nœud et les pairs de canal. Par exemple, Bob pourrait ajouter un chemin aveuglé à sa facture, permettant à Alice de payer de manière privée si son logiciel le supporte ; sinon, elle recevrait une erreur. Mouton voit cela comme une solution temporaire jusqu’à ce que les offres, qui prendront en charge nativement les chemins aveuglés, soient largement adoptées. La proposition est devenue BLIP39 en août.

Tim Ruffing et Jonas Nick ont proposé ChillDKG, un brouillon de BIP et une implémentation de référence pour générer de manière sécurisée des clés pour des signatures seuil sans script de style FROST compatibles avec les signatures schnorr de Bitcoin. ChillDKG combine un algorithme de génération de clés bien connu pour FROST avec des primitives cryptographiques modernes pour partager de manière sécurisée des composants de clé aléatoires parmi les participants tout en assurant l’intégrité et la non-censure. Il utilise l’échange de clés Diffie-Hellman sur courbe elliptique (ECDH) pour le chiffrement et la diffusion de l’authentification pour vérifier les transcriptions de sessions signées. Les participants confirment l’intégrité de la session avant d’accepter la clé publique finale. Ce protocole simplifie la gestion des clés, nécessitant que les utilisateurs sauvegardent uniquement leur graine privée et certaines données de récupération non sensibles. Les plans visant à chiffrer les données de récupération en utilisant la graine visent à améliorer la confidentialité et à simplifier davantage les sauvegardes des utilisateurs.

Juillet a vu la fusion de plusieurs BIPs qui aideront différents logiciels à interagir pour créer des signatures MuSig2. Plus tard dans le mois, Sivaram Dhakshinamoorthy a annoncé une proposition de BIP pour créer des signatures seuil sans script pour l’implémentation de Bitcoin des signatures schnorr. Cela permet à un ensemble de signataires ayant déjà effectué une procédure de configuration (par exemple, en utilisant ChillDKG) de créer de manière sécurisée des signatures qui ne nécessitent l’interaction que d’un sous-ensemble dynamique de ces signataires. Les signatures sont indiscernables onchain des signatures schnorr créées par des utilisateurs single-sig et des utilisateurs de multisignature sans script, améliorant la confidentialité et la fongibilité.

Août

Sergi Delgado a publié Hyperion, un simulateur de réseau qui suit comment les données se propagent à travers un réseau Bitcoin simulé. Le travail est initialement motivé par le désir de comparer la méthode actuelle de Bitcoin pour relayer les annonces de transactions avec la proposition de méthode Erlay.

Le développeur 0xB10C a enquêté sur la fiabilité récente de la reconstruction de bloc compact. Parfois, de nouveaux blocs incluent des transactions qu’un nœud n’a pas vues auparavant. Dans ce cas, le nœud recevant un bloc compact a généralement besoin de demander ces transactions au pair émetteur puis d’attendre que le pair réponde. Cela ralentit la propagation du bloc. La recherche a aidé à motiver la prise en compte d’une demande de PR pour activer mempoolfullrbf par défaut dans Bitcoin Core, qui a été plus tard fusionnée.

Résumé 2024 : Covenants et mises à jour de script

Plusieurs développeurs ont consacré une grande partie de leur temps en 2024 à faire avancer les propositions pour les covenants, les mises à jour de script et d’autres changements qui soutiendraient des protocoles de contrat avancés tels que joinpools et les usines à canaux.

Fin décembre 2023, Johan Torås Halseth a annoncé un programme de preuve de concept qui peut utiliser l’opcode OP_CHECKCONTRACTVERIFY de la proposition de soft fork MATT pour permettre à une partie dans un protocole de contrat de réclamer de l’argent si un programme arbitraire s’est exécuté avec succès. C’est similaire en concept à BitVM mais plus simple dans son implémentation Bitcoin en utilisant un opcode spécifiquement conçu pour la vérification de l’exécution du programme. Elftrace fonctionne avec des programmes compilés pour l’architecture RISC-V en utilisant le format ELF de Linux ; presque tous les programmeurs peuvent facilement créer des programmes pour cette cible, rendant l’utilisation d’elftrace très accessible. Halseth a fourni une mise à jour sur Elftrace en août lorsqu’il a acquis la capacité de vérifier les preuves à connaissance nulle en combinaison avec l’opcode OP_CAT.

Janvier a vu l’annonce de la proposition de soft fork combiné LNHANCE qui inclut les propositions précédentes pour OP_CHECKTEMPLATEVERIFY (CTV) et OP_CHECKSIGFROMSTACK (CSFS) ainsi qu’une nouvelle proposition pour un OP_INTERNALKEY qui place la clé interne taproot sur la pile. Plus tard dans l’année, la proposition serait mise à jour pour inclure également un opcode OP_PAIRCOMMIT qui fournit une capacité similaire à OP_CAT mais délibérément limitée dans sa composabilité. La proposition vise à permettre le déploiement de LN-Symmetry, des joinpools de style Ark, des DLCs à signature réduite, et des coffre-forts, parmi d’autres avantages décrits des propositions sous-jacentes, telles que le contrôle de congestion de style CTV et la délégation de signature de style CSFS.

Chris Stewart a publié un projet de BIP pour activer les opérations arithmétiques 64 bits dans Bitcoin Script lors d’un futur soft fork. Bitcoin permet actuellement uniquement des opérations 32 bits (en utilisant des entiers signés, donc les nombres supérieurs à environ 2 milliards ne peuvent pas être utilisés). La prise en charge des valeurs 64 bits serait particulièrement utile dans toute construction qui doit opérer sur le nombre de satoshis payés dans une sortie, car cela est spécifié en utilisant un entier 64 bits. La proposition a reçu des discussions supplémentaires à la fois en février et en juin.

Également en février, le développeur Rijndael a créé une implémentation de preuve de concept pour un coffre-fort qui dépend uniquement des règles de consensus actuelles plus la proposition d’opcode OP_CAT. Optech a comparé le coffre-fort OP_CAT aux coffre-forts possibles aujourd’hui avec des transactions pré-signées et aux coffre-forts possibles si BIP345 OP_VAULT était ajouté à Bitcoin.

Pré-signé BIP345 OP_VAULT OP_CAT avec schnorr
Disponibilité Maintenant Nécessite un soft fork de OP_VAULT et OP_CTV Nécessite un soft fork de OP_CAT
Attaque de remplacement d’adresse de dernière minute Vulnérable Non vulnérable Non vulnérable
Retraits de montants partiels Seulement si pré-arrangé Oui Non
Adresses de dépôt statiques et calculables de manière non interactive Non Oui Oui
Regroupement pour la mise en quarantaine ou le re-vaulting afin d’économiser sur les frais Non Oui Non
Efficacité opérationnelle dans le meilleur cas, c’est-à-dire uniquement pour les dépenses légitimes
(estimé très approximativement par Optech) 		2x la taille d’un single-sig régulier 3x la taille d’un single-sig régulier 4x la taille d’un single-sig régulier

En mars, le développeur ZmnSCPxj a décrit un protocole permettant de donner le contrôle d’un UTXO à une partie qui prédit correctement si un soft fork particulier sera activé ou non. D’autres ont proposé cette idée de base auparavant, mais la version de ZmnSCPxj traite des spécificités attendues pour au moins un futur soft fork potentiel, OP_CHECKTEMPLATEVERIFY.

Mars a également vu Anthony Towns commencer à travailler sur un langage de script alternatif pour Bitcoin basé sur le langage Lisp. Il a fourni un aperçu du langage de style Lisp déjà utilisé par l’altcoin Chia et a proposé un langage BTC Lisp. Plus tard dans l’année, inspiré par la relation entre Bitcoin Script et miniscript, il a divisé son projet Lisp en deux parties : un langage bitcoin lisp de bas niveau (bll) qui pourrait être ajouté à Bitcoin dans un soft fork et un langage de haut niveau symbll (symbll) qui est converti en bll. Il a également décrit une construction générique compatible avec symbll (et probablement Simplicity) qui permet de partitionner un UTXO en montants spécifiques et conditions de dépense. Il a montré comment ces marques de monnaie flexibles peuvent être utilisées, y compris des améliorations dans la sécurité et l’usabilité des canaux LN (y compris les canaux basés sur LN-Symmetry), une alternative à la version BIP345 des coffres-forts, et un design de pool de paiement.

Jeremy Rubin a proposé deux mises à jour au design de OP_CHECKTEMPLATEVERIFY en mai : la prise en charge optionnelle d’un digest de hash plus court et des engagements supplémentaires. Cela a aidé à optimiser CTV pour une utilisation dans des schémas de publication de données qui pourraient être utiles pour récupérer des données critiques dans LN-Symmetry et des protocoles similaires.

Pierre Rochard a demandé si les propositions de soft qui peuvent fournir beaucoup des mêmes fonctionnalités à un coût similaire devraient être considérés comme mutuellement exclusives, ou s’il serait logique d’activer plusieurs propositions et de laisser les développeurs utiliser l’alternative qu’ils préfèrent.

Jeremy Rubin a publié un document théorisant l’utilisation du chiffrement fonctionnel pour ajouter une gamme complète de comportements de covenant à Bitcoin sans recourir à des changements de consensus. En essence, le chiffrement fonctionnel permettrait la création d’une clé publique qui correspondrait à un programme particulier. Une partie qui pourrait satisfaire le programme serait capable de créer une signature qui correspondrait à la clé publique (sans jamais apprendre une clé privée correspondante). Cela est toujours plus privé et économisera souvent de l’espace par rapport aux covenants précédemment proposés. Malheureusement, un inconvénient majeur du chiffrement fonctionnel, selon Rubin, est qu’il s’agit d’une “cryptographie sous-développée qui la rend impraticable à utiliser actuellement”.

Anthony Towns a posté un script pour signet qui utilise OP_CAT pour permettre à quiconque de dépenser des pièces envoyées au script en utilisant la preuve de travail (PoW). Cela peut être utilisé comme un faucet de signet-bitcoin décentralisé : quand un mineur ou un utilisateur obtient des signet bitcoins en excès, ils les envoient au script. Lorsqu’un utilisateur veut plus de signet bitcoins, il cherche dans l’ensemble UTXO les paiements au script, génère du PoW, et crée une transaction qui utilise son PoW pour réclamer les pièces.

Victor Kolobov a annoncé un fonds de 1 million de dollars pour la recherche sur une proposition de soft fork pour ajouter un opcode OP_CAT. Les soumissions doivent être reçues avant le 1er janvier 2025.

En novembre, Towns a résumé l’activité sur le signet par défaut liée aux propositions de soft forks disponibles via Bitcoin Inquisition. Vojtěch Strnad, inspiré par le post de Towns, a créé un site web qui liste “chaque transaction faite sur le signet Bitcoin qui utilise l’un des soft forks déployés.”

Ethan Heilman a posté un papier qu’il a coécrit avec Victor Kolobov, Avihu Levy, et Andrew Poelstra sur la manière dont les covenants peuvent être créés facilement sans changements de consensus, bien que dépenser de ces covenants nécessiterait des transactions non standard et des millions (ou milliards) de dollars en matériel spécialisé et en électricité. Heilman note qu’une application de ce travail permettrait aux utilisateurs aujourd’hui d’inclure facilement un chemin de dépense taproot de secours qui pourrait être utilisé de manière sécurisée si une résistance quantique était soudainement nécessaire et que les opérations de signature de courbe elliptique sur Bitcoin étaient désactivées. Le travail semblait être inspiré en partie par plusieurs des recherches précédentes des auteurs sur les signatures de Lamport pour Bitcoin.

Décembre s’est conclu avec un sondage sur les opinions des développeurs concernant des propositions de covenant sélectionnées.

À partir de janvier 2025, Optech commencera à résumer les recherches et développements notables liés aux covenants, mises à jour de script, et changements connexes dans une section spéciale publiée dans la première newsletter de chaque mois. Nous encourageons tous ceux qui travaillent sur ces propositions à publier tout ce qui pourrait intéresser nos sources habituelles afin que nous puissions en parler.

Septembre

Carla Kirk-Cohen a décrit les tests et ajustements d’une mitigation de brouillage de canal hybride initialement proposée par Clara Shikhelman et Sergei Tikhomirov. Les tentatives de brouillage d’un canal pendant une heure ont principalement échoué, les attaquants dépensant soit plus que lors d’attaques connues, soit augmentant involontairement les revenus de la cible. Cependant, une attaque de trou nooir a effectivement sapé la réputation d’un nœud en sabotant les paiements à travers des routes plus courtes. Pour contrer cela, une réputation bidirectionnelle a été ajoutée à l’aval du HTLC, rapprochant la proposition d’une idée initialement proposée en 2018 par Jim Posen. Les nœuds évaluent désormais la fiabilité tant de l’expéditeur que du destinataire lorsqu’ils décident de faire suivre les paiements. Les nœuds fiables reçoivent des HTLCs avalisés, tandis que les expéditeurs ou destinataires moins fiables font face à un rejet ou à un transfert non avalisé. Ces tests ont suivi une spécification de l’aval de HTLC et une implémentation dans Eclair. Une implémentation pour LND a également été ajoutée peu avant la fin de l’année.

Jonas Nick, Liam Eagen et Robin Linus ont introduit un nouveau protocole de validation côté client (CSV), Shielded CSV, qui permet les transferts de jetons sécurisés par la preuve de travail de Bitcoin sans révéler les détails des jetons ou les historiques de transfert. Contrairement aux protocoles existants, où les clients doivent valider d’extensives historiques de jetons, Shielded CSV utilise des preuves à divulgation nulle de connaissance pour garantir que la vérification nécessite des ressources fixes tout en préservant la vie privée. De plus, Shielded CSV réduit les exigences de données onchain en regroupant des milliers de transferts de jetons dans une seule mise à jour de 64 octets par transaction Bitcoin, améliorant ainsi l’évolutivité. Le document explore le pontage sans confiance de Bitcoin vers CSV via BitVM, les structures basées sur des comptes, la gestion des réorganisations de la blockchain, les transactions non confirmées et les extensions potentielles. Ce protocole promet des améliorations significatives en termes d’efficacité et de confidentialité par rapport à d’autres systèmes de jetons.

Andy Schroder a décrit un processus pour activer les paiements LN hors ligne en générant des jetons d’authentification en ligne, permettant au portefeuille du dépensier d’autoriser les paiements via leur nœud toujours en ligne ou LSP lorsqu’ils sont hors ligne. Les jetons peuvent être transférés au destinataire via NFC ou d’autres protocoles simples, permettant les paiements sans accès à Internet. Le développeur ZmnSCPxj a proposé une alternative, et Bastien Teinturier a fait référence à sa méthode de contrôle de nœud à distance pour des cas d’utilisation similaires, améliorant les solutions de paiement hors ligne pour les appareils à ressources limitées comme les cartes intelligentes.

Octobre

La spécification BOLT12 des offres a été fusionnée. Initialement proposée en 2019, les offres permettent à deux nœuds de négocier des factures et des paiements sur LN en utilisant des messages en oignon. Les messages en oignon et les paiements compatibles avec les offres peuvent utiliser des chemins aveuglés pour empêcher le dépensier de connaître l’identité du nœud du destinataire.

Une nouvelle interface de minage pour Bitcoin Core a vu le jour avec pour objectif de soutenir les mineurs utilisant le protocole Stratum v2 qui peut être configuré pour permettre à chaque mineur de sélectionner ses propres transactions. Cependant, Anthony Towns a noté plus tôt dans l’année que la sélection indépendante des transactions pourrait augmenter les coûts de validation des parts pour les pools de minage. Si ces pools répondaient en limitant la validation, cela pourrait permettre une attaque par parts invalides similaire à la bien connue attaque par retenue de bloc. Une solution proposée en 2011 aux attaques par retenue était discutée, bien qu’elle nécessiterait un changement de consensus difficile.

Résumé 2024 : Principales sorties de projets d’infrastructure populaires

  • ● LDK 0.0.119 a ajouté la prise en charge des paiements reçus via des chemins aveuglés multi-sauts.

  • ● HWI 2.4.0 a ajouté la prise en charge de Trezor Safe 3.

  • ● Core Lightning 24.02 a inclus des améliorations au plugin recover qui “rendent les récupérations d’urgence moins stressantes”, des améliorations aux canaux d’ancrage, une synchronisation de la chaîne de blocs 50% plus rapide, et un correctif de bug pour l’analyse d’une grande transaction trouvée sur le testnet.

  • ● Eclair v0.10.0 “a ajouté la prise en charge officiel de la fonction de financement double, une implémentation à jour des offres BOLT12, et un prototype de splicing pleinement fonctionnel”.

  • ● Bitcoin Core 27.0 a déprécié libbitcoinconsensus, activé par défaut le transport P2P crypté v2, a autorisé l’utilisation de la politique de transaction opt-in topologiquement restreinte jusqu’à confirmation TRUC sur les réseaux de test, et ajouté une nouvelle stratégie de sélection de pièces à utiliser pendant les périodes de frais élevés.

  • ● BTCPay Server 1.13.1 (et les versions précédentes) rendent les webhooks plus extensibles, prennent en charge l’importation de portefeuilles multisig BIP129 et les PSBTs encodés BBQr, améliorent la flexibilité des plugins et ont commencé la migration de la prise en charge des altcoins vers des plugins.

  • ● Bitcoin Inquisition 25.2 prend en charge OP_CAT sur signet.

  • ● Libsecp256k1 v0.5.0 a accéléré la génération de clés et la signature et réduit la taille compilée “ce que [ses développeurs] s’attendent à bénéficier particulièrement aux utilisateurs embarqués.”

  • ● LDK v0.0.123 a inclus une mise à jour de ses paramètres pour les HTLCs coupés et des améliorations à la prise en charge des offres.

  • ● Bitcoin Inquisition 27.0 a ajouté l’application de OP_CAT sur signet comme spécifié dans BIN24-1 et BIP347. Il a également inclus “une nouvelle sous-commande evalscript pour bitcoin-util qui peut
    1. être utilisée pour tester le comportement des opcodes de script”. La prise en charge de annexdatacarrier et des pseudo ancres éphémères a été supprimée.

  • ● LND v0.18.0-beta prend en charge de façon expérimentale les frais de routage entrants, la recherche de chemin pour les chemins aveuglés, les watchtowers pour les canaux taproot simples, et a simplifié l’envoi d’informations de débogage cryptées.

  • ● Core Lightning 24.05 a amélioré la compatibilité avec les nœuds complets élagués, permet au RPC check de fonctionner avec des plugins, permet une livraison plus robuste des factures d’offre, et a corrigé un problème de surpaiement de frais lorsque l’option de configuration ignore_fee_limits est utilisée.

  • ● HWI 3.1.0 prend en charge Trezor Safe 5.

  • ● Bitcoin Core 28.0 prend en charge le testnet4, l’opportunisme un-parent-un-enfant (1p1c) des relais de paquets, relais par défaut des transactions opt-in topologiquement restreintes jusqu’à confirmation (TRUC), relais par défaut des transactions pay-to-anchor, relais limité de paquets RBF, et full-RBF par défaut. Les paramètres par défaut pour assumeUTXO ont été ajoutés, permettant l’utilisation de la RPC loadtxoutset avec un ensemble UTXO téléchargé en dehors du réseau Bitcoin (par exemple, via un torrent).

  • ● BTCPay Server 2.0.0 a ajouté “une meilleure localisation, une navigation latérale, un flux d’intégration amélioré, des options de personnalisation améliorées, [et] prend en charge les fournisseurs de taux plugables.” La mise à niveau comprend quelques changements majeurs et des migrations de base de données.

  • ● Libsecp256k1 0.6.0 “a ajouté un module MuSig2, une méthode significativement plus robuste pour effacer les secrets de la pile, et a supprimé les fonctions secp256k1_scratch_space inutilisées.”

  • ● BDK 0.30.0 est préparé pour la mise à niveau anticipée à la version 1.0 de la bibliothèque.

  • ● Eclair v0.11.0 “prend en charge les offres BOLT12 et a progressé sur les fonctionnalités de gestion de liquidité (splicing, publicités de liquidité, et financement à la volée).” La version a également cessé d’accepter de nouveaux canaux non-ancré.

  • ● Core Lightning 24.11 contenait un nouveau plugin expérimental pour effectuer des paiements utilisant une sélection de route avancée ; payer et recevoir des paiements vers les offres était activé par défaut ; et plusieurs améliorations au splicing ont été ajoutées.

Novembre

ZmnSCPxj a proposé la conception SuperScalar pour un channel factory utilisant des arborescences à délai d’expiration afin de permettre aux utilisateurs de LN d’ouvrir des canaux et d’accéder à la liquidité de manière plus abordable tout en maintenant l’absence de confiance. La conception utilise une arborescence à délai d’expiration superposé qui exige que le fournisseur de services paie tous les coûts de mise de l’arborescence onchain ou perde tous les fonds restants dans l’arborescence. Cela encourage le fournisseur de services à inciter les utilisateurs à fermer leurs canaux de manière coopérative pour éviter le besoin d’aller onchain. La conception utilise à la fois des canaux de micropaiement duplex et des canaux de paiement LN-Penalty, tous deux possibles sans aucun changement de consensus. Malgré sa complexité—combinant plusieurs types de canaux et gérant l’état offchain—la conception peut être mise en œuvre par un seul vendeur sans nécessiter de grands changements de protocole. Pour soutenir la conception, ZmnSCPxj a plus tard proposé un ajustement de channel factory pluggable à la spécification LN.

John Law a proposé un protocole de micropaiement de résolution de paiement offchain (OPR) qui exige que les deux participants contribuent à un fonds pouvant être effectivement détruit à tout moment par l’un ou l’autre participant. Cela crée une incitation pour les deux parties à apaiser l’autre ou risquer une destruction mutuelle assurée (MAD) des fonds liés. Le protocole n’est pas sans confiance, mais il est plus évolutif que les alternatives, offre une résolution rapide et n’oblige pas les parties à publier des données onchain avant l’expiration des verrous temporels. Cela peut rendre OPR beaucoup plus efficace à l’intérieur d’un channel factory, d’arborescence à délai d’expiration, ou autre structure imbriquée qui idéalement garderait les portions imbriquées offchain.

Résumé 2024 : Bitcoin Optech

Pour la septième année d’Optech, nous avons publié 51 bulletins d’information hebdomadaires et ajouté 35 nouvelles pages à notre index des sujets. En tout, Optech a publié plus de 120 000 mots en anglais sur la recherche et le développement logiciel Bitcoin cette année, l’équivalent approximatif d’un livre de 350 pages.

Chaque bulletin et article de blog a été traduit en chinois, tchèque, français et japonais, totalisant plus de 200 traductions en 2024.

De plus, chaque bulletin de cette année a été accompagné d’un épisode de podcast, totalisant plus de 59 heures sous forme audio et 488 000 mots sous forme de transcript. De nombreux contributeurs de premier plan de Bitcoin ont été invités à l’émission - certains à plus d’un épisode

  • avec un total de 75 invités uniques différents en 2024 :

  • Abubakar Sadiq Ismail (x2)
  • Adam Gibson
  • Alex Bosworth
  • Andrew Toth (x3)
  • Andy Schroder
  • Anthony Towns (x5)
  • Antoine Poinsot (x5)
  • Antoine Riard (x2)
  • Armin Sabouri
  • Bastien Teinturier (x4)
  • Bob McElrath
  • Brandon Black (x3)
  • Bruno Garcia
  • callebtc
  • Calvin Kim
  • Chris Stewart (x3)
  • Christian Decker
  • Dave Harding (x3)
  • David Gumberg
  • /dev/fd0
  • Dusty Daemon
  • Elle Mouton (x2)
  • Eric Voskuil
  • Ethan Heilman (x2)
  • Eugene Siegel
  • Fabian Jahr (x5)
  • Filippo Merli
  • Gloria Zhao (x10)
  • Gregory Sanders (x7)
  • Hennadii Stepanov
  • Hunter Beast
  • Jameson Lopp (x2)
  • Jason Hughes
  • Jay Beddict
  • Jeffrey Czyz
  • Johan Torås Halseth
  • Jonas Nick (x2)
  • Joost Jager
  • Josie Baker
  • Kulpreet Singh
  • Lorenzo Bonazzi
  • Luke Dashjr
  • Matt Corallo (x3)
  • Moonsettler (x2)
  • Nicholas Gregory
  • Niklas Gögge (x2)
  • Oghenovo Usiwoma
  • Olaoluwa Osuntokun
  • Oliver Gugger
  • Peter Todd
  • Pierre Corbin
  • Pierre Rochard
  • Pieter Wuille
  • René Pickhardt (x2)
  • Richard Myers
  • Rijndael
  • rkrux
  • Russell O’Connor
  • Salvatore Ingala (x2)
  • Sebastian Falbesoner
  • SeedHammer Team
  • Sergi Delgado
  • Setor Blagogee
  • Shehzan Maredia
  • Sivaram Dhakshinamoorthy
  • Stéphan Vuylsteke
  • Steven Roose
  • Tadge Dryja
  • TheCharlatan
  • Tom Trevethan- Tony Klausing
  • Valentine Wallace
  • Virtu
  • Vojtěch Strnad (x2)
  • ZmnSCPxj (x3)

Optech a eu la chance et est reconnaissant d’avoir reçu une contribution de 20 000 USD de la part de la Fondation pour les Droits de l’Homme. Ces fonds seront utilisés pour payer l’hébergement web, les services de messagerie, les transcriptions de podcasts et d’autres dépenses qui nous permettent de continuer et d’améliorer notre diffusion de contenu technique à la communauté Bitcoin.

Décembre

Décembre a vu la continuation de plusieurs discussions et l’annonce de multiples vulnérabilités, toutes résumées plus tôt dans ce bulletin.

Nous remercions tous les contributeurs Bitcoin nommés ci-dessus, ainsi que les nombreux autres dont le travail était tout aussi important, pour une autre année incroyable de développement Bitcoin. Le bulletin hebdomadaire Optech reprendra son calendrier de publication régulier le vendredi 3 janvier.