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

Contenus

Janvier

  • ● Brouillon mis à jour de ChillDKG : Tim Ruffing et Jonas Nick ont mis à jour leur travail sur un protocole de génération de clés distribué (DKG) pour utilisation avec le schéma de signature à seuil FROST. ChillDKG vise à fournir des fonctionnalités de récupération similaires aux portefeuilles descripteurs existants.
  • ● DLC offchain : Le développeur Conduition a posté à propos d’un nouveau mécanisme de DLC (contrat à log discret) offchain qui permet aux participants de collaborer à la création et à l’extension d’une usine de DLC, ce qui permet des DLC itératifs qui se poursuivent jusqu’à ce qu’une partie choisisse de résoudre onchain. Cela contraste avec les travaux antérieurs sur les DLC offchain qui nécessitaient une interaction à chaque renouvellement du contrat.

  • ● Reconstructions de blocs compacts : Janvier a également vu le premier de plusieurs éléments en 2025 qui ont revisité les recherches précédentes sur l’efficacité avec laquelle les nœuds Bitcoin reconstruisent des blocs en utilisant le relais de blocs compacts (BIP152), en mettant à jour les mesures précédentes et en explorant des raffinements potentiels. Les statistiques mises à jour publiées en janvier ont montré que lorsque les mémoires tampons sont pleines, les nœuds doivent plus fréquemment demander des transactions manquantes. Une mauvaise résolution des orphelins a été identifiée comme une cause possible, avec quelques améliorations déjà réalisées.

    Plus tard dans l’année, une analyse a examiné si les stratégies de préremplissage de blocs compacts pourraient améliorer davantage le succès de la reconstruction. Les tests ont suggéré que le préremplissage sélectif de transactions susceptibles de manquer dans les mémoires tampons des pairs pourrait réduire les demandes de secours avec seulement des compromis modestes en termes de bande passante. Des recherches ultérieures ont ajouté ces mesures supplémentaires et mis à jour les mesures de reconstruction dans le monde réel avant et après les changements apportés aux taux minimum de frais de relais des nœuds de surveillance, montrant que les nœuds avec un minrelayfee plus bas ont un taux de reconstruction plus élevé. L’auteur a également posté sur l’architecture derrière son projet de surveillance.

Février

  • ● Scripts d’ancrage éphémères LN : Après plusieurs mises à jour des politiques de mempool dans Bitcoin Core 28.0, la discussion a commencé en février autour des choix de conception pour les ancrages éphémères dans les transactions d’engagement LN. Les contributeurs ont examiné quelles constructions de scripts devraient être utilisées comme l’un des outputs des transactions d’engagement basées sur TRUC en remplacement des ancrages existants.

    Les compromis incluaient comment différents scripts affectent le bumping de frais CPFP, le poids de la transaction, et la capacité à dépenser ou à jeter en toute sécurité les sorties d’ancrage lorsqu’ils ne sont plus nécessaires. La discussion continue a mis en évidence les interactions avec la politique de mempool et les hypothèses de sécurité de Lightning.

  • ● Paiements probabilistes : Oleksandr Kurbatov a lancé une discussion sur Delving Bitcoin sur les méthodes de production de résultats aléatoires à partir de scripts Bitcoin. La méthode originale utilise des preuves à divulgation nulle de connaissance dans un arrangement challenger/vérificateur et dispose maintenant d’un concept prouvé publié. D’autres méthodes ont été discutées, incluant une exploitation de la structure arborescente de taproot, et une méthode qui scripte le XOR de bits représentés par une séquence de différentes fonctions de hachage pour produire directement une chaîne de bits imprévisible. Il y a eu discussion sur le fait que de tels résultats de transactions aléatoires pourraient être utilisés pour produire des HTLCs probabilistes comme alternative aux HTLCs réduits pour de petits montants dans LN.

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

En 2025, Optech a résumé plus d’une douzaine de divulgations de vulnérabilités. Les rapports de vulnérabilité aident les développeurs et les utilisateurs à apprendre des erreurs passées, et les divulgations responsables garantissent que les correctifs sont publiés avant que les vulnérabilités puissent être exploitées.

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 mentionnées dans cette section pour leur perspicacité et leur préoccupation claire pour la sécurité des utilisateurs.

Début janvier, Yuval Kogman a divulgué publiquement plusieurs faiblesses de déanonymisation de longue date dans les protocoles de coinjoin centralisés utilisés par les versions actuelles de Wasabi et Ginger, ainsi que dans les versions passées de Samourai, Sparrow et Trezor Suite. Si exploitées, un coordinateur centralisé pourrait lier les entrées d’un utilisateur à ses sorties, enlevant effectivement les avantages de confidentialité attendus du coinjoin. Une vulnérabilité similaire a également été signalée fin 2024 (voir le Bulletin #333).

Fin janvier, Matt Morehouse a annoncé la divulgation responsable d’une vulnérabilité dans le traitement des réclamations de LDK lors de fermetures unilatérales avec de nombreux HTLCs en attente. LDK visait à réduire les frais en regroupant plusieurs résolutions HTLC ; cependant, si des conflits survenaient avec des confirmations de transactions provenant d’un contrepartie de canal, LDK pourrait ne pas mettre à jour tous les lots affectés, conduisant à des fonds bloqués et même à un risque de vol. Ce problème a été résolu dans LDK 0.1.

Cette même semaine, Antoine Riard a révélé une vulnérabilité supplémentaire utilisant l’attaque de replacement cyclique. Un attaquant pourrait l’exploiter en épinglant une transaction non confirmée de la victime, en recevant et ne propageant pas les remplacements de frais de la victime, puis en minant sélectivement la version à frais les plus élevés de la victime. Ce scénario nécessitait des conditions rares et serait difficile à maintenir sans être détecté.

En février, Morehouse a révélé une seconde vulnérabilité LDK : si de nombreux HTLC avaient le même montant et le même hash de paiement, LDK échouerait à régler tous les HTLC sauf un, conduisant les contreparties honnêtes à forcer la fermeture des canaux. Bien que cela n’ait pas permis de vol direct, cela a résulté en des frais supplémentaires et une réduction des revenus de routage jusqu’à ce que le bug soit corrigé dans LDK 0.1.1 (voir le Bulletin #340).

En mars, Morehouse a annoncé la divulgation responsable d’une vulnérabilité LND corrigée dans les versions antérieures à 0.18 : un attaquant avec un canal vers la victime pourrait amener LND à payer et rembourser le même HTLC s’il pouvait également d’une manière ou d’une autre provoquer le redémarrage du nœud de la victime. Cela permettrait à l’attaquant de voler presque la totalité de la valeur du canal. La divulgation a également mis en évidence des lacunes dans la spécification Lightning, qui ont été corrigées plus tard (voir le Bulletin #346).

En mai, Ruben Somsen a décrit un cas limite théorique de défaillance de consensus lié au traitement historique par BIP30 des transactions coinbase en doublons. Avec les points de contrôle retirés de Bitcoin Core (voir le Bulletin #346), une réorganisation extrême des blocs jusqu’au bloc 91,842 pourrait laisser les nœuds avec des ensembles UTXO différents, selon qu’ils aient observé ou non les coinbases doublons. Plusieurs solutions ont été discutées, telles que l’ajout de logique spéciale pour ces deux exceptions ; cependant, cela n’était pas considéré comme une menace réaliste.

Également en mai, Antoine Poinsot a annoncé la divulgation responsable d’une vulnérabilité de faible gravité affectant les versions de Bitcoin Core antérieures à 29.0 où des publicités d’adresses excessives pourraient déborder un identifiant 32 bits et faire planter le nœud. Des atténuations antérieures avaient déjà rendu l’exploitation pratiquement lente sous les limites de pairs par défaut (voir les Bulletins #159 et #314), et le problème a été entièrement résolu en passant à des identifiants 64 bits dans Bitcoin Core 29.0.

En juillet, Morehouse a annoncé la divulgation responsable d’un problème de déni de service LND dans lequel un attaquant pourrait demander à plusieurs reprises des messages d’historiques gossip jusqu’à ce que le nœud épuise sa mémoire et plante. Ce bug a été corrigé dans LND 0.18.3 (voir le Bulletin #319). En septembre, Morehouse a révélé une vulnérabilité dans les anciennes versions d’Eclair : un attaquant pourrait diffuser une ancienne transaction d’engagement pour voler tous les fonds actuels d’un canal, et Eclair l’ignorerait. La correction d’Eclair était accompagnée d’une mesure plus une suite de tests complète destinée à détecter des problèmes potentiels similaires. En octobre, Poinsot a publié quatre vulnérabilités de Bitcoin Core de faible gravité, divulguées de manière responsable, couvrant deux bugs de remplissage de disque, un crash à distance hautement improbable affectant les systèmes 32 bits, et un problème de DoS CPU dans le traitement des transactions non confirmées. Ces problèmes ont été partiellement résolus dans la version 29.1 et entièrement résolus dans la version 30.0, voir les Bulletins #361, #363, et #367 pour quelques-unes des corrections.

En décembre, Bruno Garcia a divulgué une défaillance théorique du consensus dans la bibliothèque NBitcoin liée à OP_NIP qui pourrait déclencher une exception dans un cas limite spécifique de pile en pleine capacité. Elle a été découverte en utilisant le fuzzing différentiel et rapidement corrigée. Aucun nœud complet n’est connu pour utiliser NBitcoin, il n’y avait donc aucun risque pratique de division de chaîne résultant de la divulgation.

En décembre, Morehouse a également divulgué trois vulnérabilités critiques dans LND incluant deux vulnérabilités de vol de fonds et une vulnérabilité de déni de service.

Mars

  • ● Marché privé de templates de blocs pour prévenir la centralisation du MEV : Les développeurs Matt Corallo et 7d5x9 ont posté sur Delving Bitcoin une proposition qui pourrait aider à prévenir un futur dans lequel existe MEVil, une forme de valeur extractible par les mineurs (MEV) menant à la centralisation du minage, et prolifère sur Bitcoin. La proposition, appelée MEVpool, permettrait aux parties d’enchérir sur des marchés publics pour un espace sélectionné dans les templates de blocs des mineurs (par exemple, “Je paierai X [BTC] pour inclure la transaction Y tant qu’elle vient avant toute autre transaction qui interagit avec le contrat intelligent identifié par Z”).

    Bien que les services d’ordonnancement préférentiel des transactions dans les templates de blocs soient attendus pour être fournis uniquement par de grands mineurs, menant à la centralisation, un marché public réduit en confiance permettrait à tout mineur de travailler sur des templates de blocs aveuglés, dont les transactions complètes ne sont pas révélées aux mineurs jusqu’à ce qu’ils aient produit suffisamment de preuve de travail pour publier le bloc. Les auteurs ont averti que cette proposition nécessiterait plusieurs marchés concurrent afin de préserver la décentralisation contre la dominance d’un seul marché de confiance.

  • ● Frais initiaux et de maintien sur LN utilisant des sorties brûlables : John Law a proposé une solution aux attaques de blocage de canal, une faiblesse dans le protocole du Lightning Network qui permet à un attaquant d’empêcher sans coût les autres nœuds d’utiliser leurs fonds. La proposition résume un document qu’il a écrit sur la possibilité des nœuds Lightning pour charger deux types supplémentaires de frais pour le transfert de paiements, un frais initial et un frais de rétention. Le dépensier final paierait le premier pour compenser les nœuds de transfert pour l’utilisation temporaire d’un emplacement HTLC, tandis que le dernier serait payé par tout nœud qui retarde le règlement d’un HTLC, avec le montant des frais augmentant avec la durée du retard.

Avril

  • ● Accélerateur SwiftSync pour le téléchargement initial de bloc : Sebastian Falbesoner a publié sur Delving Bitcoin une implémentation exemple et les résultats d’une accélération de plus de 5x du téléchargement initial de bloc (IBD) grâce à SwiftSync, une idée initialement proposée par Ruben Somsen.

    L’accélération est réalisée pendant l’IBD en ajoutant uniquement les pièces à l’ensemble UTXO lorsqu’elles seront encore dans l’ensemble UTXO à la fin de l’IBD. Cette connaissance de l’état final de l’ensemble UTXO est compactement encodée dans un fichier d’indices pré-généré, minimement fiable. En plus de minimiser la surcharge des opérations sur l’état de la chaîne, SwiftSync permet d’autres améliorations de performance en autorisant la validation parallèle des blocs.

    Le travail sur une implémentation en Rust a été annoncé en septembre.

  • ● Signatures agrégées interactives DahLIAS : En avril, Jonas Nick, Tim Ruffing et Yannick Seurin ont annoncé à la liste de diffusion Bitcoin-Dev leur document DahLIAS, le premier schéma de signature agrégée interactive de 64 octets compatible avec les primitives cryptographiques déjà utilisées dans Bitcoin. Les signatures agrégées sont la condition cryptographique pour l’agrégation de signature inter-entrées (CISA), une fonctionnalité proposée pour Bitcoin qui pourrait réduire la taille des transactions avec plusieurs entrées, réduisant ainsi le coût de nombreux types de dépenses, coinjoins et payjoins inclus.

Résumé 2025 : Quantum

Avec l’attention accrue sur le potentiel d’un futur ordinateur quantique pour affaiblir ou briser l’hypothèse de dureté du logarithme discret de courbe elliptique (ECDL) sur laquelle Bitcoin repose pour prouver la propriété des pièces, plusieurs conversations et propositions ont été avancées tout au long de l’année pour discuter et atténuer l’impact d’un tel développement.

Clara Shikhelman et Anthony Milton ont publié un document couvrant les impacts de l’informatique quantique sur Bitcoin et esquissant des stratégies d’atténuation potentielles.

BIP360 a été mis à jour et a reçu son numéro BIP. Cette proposition a suscité de l’intérêt à la fois comme un premier pas vers le renforcement quantique de Bitcoin et une optimisation pour les cas d’utilisation de taproot qui ne nécessitent pas de clé interne. La recherche plus tard dans l’année a confirmé la sécurité de ces engagements taproot contre la manipulation par des ordinateurs quantiques. Vers la fin de l’année, la proposition a été renommée en P2TSH (pay to tapscript hash) au lieu du nom précédent P2QRH (pay to quantum resistant hash), reflétant sa portée réduite et sa généralité accrue.

Jesse Posner a mis en évidence les recherches existantes qui indique que les primitives Bitcoin existantes telles que les portefeuilles déterministes hiérarchiques (HD), les paiements silencieux, l’agrégation de clés et les signatures seuils pourraient être compatibles avec certains des algorithmes de signature résistants aux quantiques fréquemment référencés.

Augustin Cruz a proposé un BIP pour détruire avec certitude les pièces vulnérables aux quantiques. Par la suite, Jameson Lopp a lancé une discussion sur la manière dont les pièces vulnérables aux quantiques devraient être traitées, ce qui a mené à plusieurs idées allant de laisser l’adversaire quantique les avoir à les détruire. Lopp a plus tard proposé une séquence concrète de soft forks que Bitcoin pourrait implémenter, commençant bien avant qu’un Ordinateur Quantique Cryptographiquement Pertinent (CRQC) soit développé pour atténuer progressivement la menace d’un adversaire quantique soudainement capable d’accéder à de nombreuses pièces, tout en permettant aux détenteurs de sécuriser leurs pièces.

Deux propositions (1, 2) ont été faites pour permettre à la plupart des pièces existantes d’être sécurisées d’une manière qui pourrait être récupérée dans l’événement où Bitcoin désactiverait les dépenses vulnérables aux quantiques à un moment ultérieur. Brièvement, la séquence d’événements théorisée est 0) les détenteurs de bitcoin s’assurent que leurs portefeuilles actuels ont un secret haché requis pour un certain chemin de dépense 1) un CRQC est montré comme imminent, 2) Bitcoin désactive les signatures de courbe elliptique, 3) Bitcoin active un schéma de signature sécurisé quantique, 4) Bitcoin active l’une de ces propositions permettant aux détenteurs préparés de réclamer leurs pièces vulnérables aux quantiques. Selon l’implémentation exacte, n’importe quel type d’adresse (y compris P2TR avec un scriptpath) pourrait tirer avantage de ces méthodes.

Le développeur Conduition a démontré que OP_CAT peut être utilisé pour implémenter des signatures Winternitz, qui fournissent une vérification de signature résistante aux quantiques à un coût d’environ 2000 vbytes par entrée. Cela coûte moins cher que les signatures précédemment proposées basées sur OP_CAT Lamport.

Matt Corallo a commencé une discussion autour de l’idée générale d’ajouter un opcode de vérification de signature résistant aux quantiques à tapscript. Plus tard, Abdelhamid Bakhta a proposé la vérification native STARK comme un tel opcode, et Conduition a écrit sur leur travail d’optimisation des signatures quantiques résistantes SLH-DSA (SPHINCS) comme une autre option. Tout opcode de vérification de signature résistant aux quantiques incluant OP_CAT ajouté à tapscript pourrait être combiné avec BIP360 pour durcir complètement les sorties Bitcoin contre les quantiques.

Tadge Dryja a proposé une manière dont Bitcoin pourrait implémenter l’agrégation de signature inter-entrées générale qui atténuerait partiellement la grande taille des signatures post-quantiques.

À la fin de l’année, Mikhail Kudinov et Jonas Nick ont publié un document qui fournit un aperçu des schémas de signature basés sur le hachage et discute de la manière dont ceux-ci pourraient être adaptés aux besoins de Bitcoin.

Mai

  • ● Cluster mempool : Au début de l’année, Stefan Richter a suscité l’enthousiasme en découvrant qu’un algorithme efficace pour le problème de maximum-ratio closure issu d’un article de recherche de 1989 pourrait être appliqué à la linéarisation des clusters. Pieter Wuille enquêtait déjà sur une approche de programmation linéaire comme amélioration potentielle par rapport à la recherche initiale de l’ensemble des candidats et a intégré l’exploration de l’approche basée sur la coupe minimale comme une troisième option dans sa recherche. Un peu plus tard, Wuille a guidé le Bitcoin Core PR Review Club à travers la nouvelle classe TxGraph qui distille les transactions pour ne conserver que le poids, les frais et les relations pour une interaction efficace avec le graphe du mempool. En mai, Wuille a publié des benchmarks favorables et décrit les compromis des trois approches de linéarisation des clusters, déterminant que les deux approches avancées étaient bien plus efficaces que la simple recherche de l’ensemble des candidats, mais que son algorithme de linéarisation de forêt couvrante basé sur la programmation linéaire serait plus pratique que l’approche basée sur la coupe minimale. À l’automne, Abubakar Sadiq Ismail a décrit comment le mempool des clusters pourrait être utilisé pour suivre quand le contenu du mempool s’était considérablement amélioré par rapport à un modèle de bloc précédent. Vers la fin de l’année, l’implémentation du mempool des clusters a été achevée, la préparant à être publiée avec Bitcoin Core 31.0. Le travail pour remplacer l’algorithme de linéarisation de recherche de l’ensemble des candidats initiaux par l’algorithme de linéarisation de forêt couvrante est en cours.
  • ● Augmenter ou supprimer la limite de politique OP_RETURN de Bitcoin Core : En avril, les développeurs de protocole ont découvert que les limites de politique de sortie OP_RETURN provoquaient un mal incitatif à intégrer des données dans les sorties de paiement sous certaines circonstances. En plus de l’observation que les motivations originales pour la politique avaient été dépassées par le réseau, cela a incité une proposition pour supprimer les limites de politique du mempool OP_RETURN. Cette proposition a déclenché un chaud débat sur l’efficacité de la politique du mempool, le but de Bitcoin, et la responsabilité des développeurs de Bitcoin de réguler ou de s’abstenir de réguler l’utilisation de Bitcoin. Les contributeurs de Bitcoin Core ont argué que les incitations économiques rendaient peu probable que les sorties OP_RETURN voient un usage drastiquement plus important et ont considéré le changement comme la correction du bug d’incitation. Les critiques ont interprété la suppression des limites comme une approbation de l’intégration de données, mais ont également convenu que cela est économiquement peu attrayant pour être utilisé de cette manière. Finalement, la version Bitcoin Core 30.0 a été livrée avec une politique mise à jour, pour permettre plusieurs sorties OP_RETURN et supprimer la limite de politique sur la taille pour les scripts de sortie OP_RETURN. Après la sortie, plusieurs propositions de soft fork ont été mises en avant, proposant de limiter l’intégration de données au niveau du consensus.

Juin

  • ● Calculer le seuil de danger du minage égoïste : Antoine Poinsot a fourni une explication approfondie des mathématiques derrière l’attaque de minage égoïste, basée sur le papier de 2013 qui a donné son nom à cette exploit. Poinsot s’est concentré sur la reproduction d’une des conclusions du papier, prouvant qu’un mineur malhonnête contrôlant 33% du hashrate total du réseau peut devenir marginalement plus rentable que les autres mineurs en retardant sélectivement l’annonce de certains des nouveaux blocs qu’il trouve.
  • ● Empreintes digitales des nœuds utilisant les messages addr : Les développeurs Daniela Brozzoni et Naiyoma ont présenté les résultats de leur recherche sur les empreintes digitales, qui se concentrait sur l’identification du même nœud sur plusieurs réseaux en utilisant les messages addr, envoyés par les nœuds, à travers le protocole P2P, pour annoncer d’autres pairs potentiels. Brozzoni et Naiyoma ont réussi à identifier les nœuds individuellement en utilisant les détails de leurs messages d’adresse spécifiques, leur permettant d’identifier le même nœud fonctionnant sur plusieurs réseaux (tels que IPv4 et Tor). Les chercheurs ont suggéré deux atténuations possibles : soit supprimer entièrement les horodatages des messages d’adresse, soit les randomiser légèrement pour les rendre moins spécifiques à des nœuds particuliers.

  • ● Verrous embrouillés : En juin, Robin Linus a présenté une proposition pour améliorer les contrats de style BitVM, basée sur une idée de Jeremy Rubin. La nouvelle approche tire parti des circuits embrouillés, un primitif cryptographique qui rend la vérification SNARK onchain mille fois plus efficace que l’implémentation BitVM2, promettant une réduction significative de la quantité d’espace onchain nécessaire. Cependant, cela nécessite une configuration offchain de plusieurs téraoctets.

    Plus tard, en août, Liam Eagen a posté sur la liste de diffusion Bitcoin-Dev à propos de son article décrivant un nouveau mécanisme pour créer des contrats de calcul responsables basés sur des circuits embrouillés, appelé Glock (verrous embrouillés). Bien que l’approche soit similaire, la recherche d’Eagen est indépendante de celle de Linus. Selon Eagen, Glock permet une réduction de 550x des données onchain par rapport à BitVM2.

Résumé 2025 : Propositions de soft fork

Cette année a vu une multitude de discussions autour des propositions de soft fork, allant de celles à portée limitée et à impact minimal, à celles à portée large et puissante.

  • ● Modèles de transaction : Plusieurs ensembles de soft fork ont été discutés autour des modèles de transaction. Avec une portée et une capacité similaires, il y a CTV+CSFS (BIP119+BIP348) et le paquet de signature réaffectable natif de taproot (OP_TEMPLATEHASH+BIP348+BIP349). Ces propositions représentent l’amélioration minimale de la capacité pour le Script Bitcoin pour permettre à la fois des signatures réaffectables (signatures qui ne s’engagent pas à dépenser un UTXO spécifique), et un pré-engagement à dépenser un UTXO pour une transaction suivante spécifique (parfois appelé un covenant d’égalité). Si activées, elles permettraient LN-Symmetry et les coffre-forts simple CTV, réduire les exigences de signature DLC, réduire l’interactivité pour les Arks, simplifier les PTLCs, et plus. Une différence entre ces propositions est que OP_TEMPLATEHASH ne peut pas être utilisé dans le BitVM sibling hack où CTV peut, parce que OP_TEMPLATEHASH ne s’engage pas sur les scriptSigs.

    En incluant OP_CHECKSIGFROMSTACK, ces propositions permettent également des engagements multiples (s’engager sur plusieurs valeurs liées et optionnellement ordonnées dans un script de verrouillage ou de dépense) similaires aux arbres de Merkle grâce au Key Laddering. La proposition mise à jour de LNHANCE inclut OP_PAIRCOMMIT (BIPs #1699) pour permettre des engagements multiples sans la taille de script supplémentaire et le coût de validation requis pour le Key Laddering. Les engagements multiples sont utiles dans LN-Symmetry, les délégations complexes, et plus encore.

    Certains développeurs ont exprimé leur frustration concernant (de leur point de vue) la lente progression vers un soft fork, mais le volume de discussion autour de cette catégorie de proposition suggère que l’intérêt et l’enthousiasme restent élevés.

  • ● Nettoyage du consensus : La proposition de nettoyage du consensus a été mise à jour sur la base des retours et des recherches supplémentaires, un brouillon de BIP a été publié et fusionné en tant que BIP54 et inclut maintenant une implémentation et des vecteurs de test. Plus tôt cette année, il y a eu discussion sur le fait que de tels nettoyages devraient être rendus temporaires en cas de confiscation involontaire, mais la nécessité de réévaluer un tel soft fork temporaire à chaque expiration rend ces soft forks temporaires moins attrayants.

  • ● Propositions d’opcode : En plus des propositions d’opcode groupées discutées ci-dessus, plusieurs autres opcodes individuels de Script ont été proposés ou affinés en 2025.

    OP_CHECKCONTRACTVERIFY (CCV) est devenu BIP443 avec des sémantiques affinées, en particulier concernant le flux de fonds. CCV permet des coffre-forts de sécurité réactive, et un large éventail d’autres contrats en contraignant le scriptPubKey et le montant d’une entrée ou sortie de certaines manières. La proposition OP_VAULT a été retirée en faveur de CCV. Pour plus d’informations sur les applications de CCV, voir l’entrée du topic d’Optech.

    Un ensemble d’opcodes arithmétiques de 64 bits a été proposé. Les opérations mathématiques actuelles de Bitcoin ne sont (surprenamment) pas capables d’opérer sur la gamme complète des montants d’entrée et de sortie de Bitcoin. Combinées avec d’autres opcodes pour accéder et/ou contraindre les montants d’entrée/sortie, ces opérations arithmétiques étendues pourraient permettre de nouvelles fonctionnalités de portefeuille Bitcoin.

    Une variante proposée de OP_TXHASH permettrait le parrainage de transactions.

    Les développeurs ont proposé deux options pour donner à Script des opérations cryptographiques sur courbes elliptiques autres que OP_CHECKSIG et les opérations liées. L’une propose OP_TWEAKADD pour permettre de construire des scriptPubKeys taproot. L’autre propose des opcodes de courbe elliptique plus granulaires, tels que EC_POINT_ADD, motivés par une fonctionnalité similaire, mais avec des applications plus larges, telles que de nouvelles vérifications de signature ou des fonctionnalités de multisignature. Combiner l’une de ces propositions avec OP_TXHASH et l’arithmétique 64 bits (ou des opcodes similaires) permettrait une fonctionnalité similaire à CCV.

  • ● Restauration de Script : Une série de quatre BIPs a été publiée pour le projet de Restauration de Script. Les changements de Script et les opcodes proposés dans ces quatre BIPs permettraient toute la fonctionnalité proposée dans les propositions d’opcode précédentes tout en permettant une plus grande expressivité de script.

Juillet

  • ● Délégation de code chaîne : Jurvis Tan a publié sur son travail avec Jesse Posner sur une méthode (désormais appelée Délégation de Code Chaîne/BIP89) pour la garde collaborative où le client, plutôt que le fournisseur de garde collaborative partiellement fiable, génère (et garde privé) le code chaîne BIP32 pour dériver les clés enfant de la clé de signature du fournisseur. De cette manière, le fournisseur ne peut pas dériver l’arbre complet des clés du client. La méthode peut être utilisée soit de manière aveugle (pour une confidentialité complète tout en tirant parti de la sécurité de la clé du fournisseur) soit de manière non aveugle (permettant au fournisseur d’appliquer une politique au prix de la révélation des transactions spécifiques signées au fournisseur).

Août

  • ● Brouillons de BIP Utreexo : Calvin Kim, Tadge Dryja et Davidson Souza ont co-écrit trois brouillons de BIP pour une alternative à la conservation de l’ensemble complet des UTXO, appelée Utreexo, qui permet aux nœuds d’obtenir et de vérifier des informations sur les UTXOs dépensés dans une transaction. La proposition utilise une forêt d’arbres de Merkle pour accumuler des références à chaque UTXO, permettant aux nœuds d’éviter de stocker les sorties.

    Depuis août, la proposition a reçu des retours, et les BIPs ont été numérotés :

    • BIP181 : Décrit l’accumulateur Utreexo et ses opérations.

    • BIP182 : Définit les règles pour valider les blocs et les transactions en utilisant l’accumulateur Utreexo.

    • BIP183 : Définit les changements nécessaires pour que les nœuds puissent échanger une preuve d’inclusion, confirmant les UTXOs dépensés.

  • ● Abaissement du taux de frais minimum de relais : Après que la réduction du taux de frais minimum de relais des transactions ait été discutée plusieurs fois au cours des dernières années, fin juin, certains mineurs ont soudainement commencé à inclure des transactions payant moins que le taux de frais minimum de relais par défaut de 1 sat/vbyte dans leurs blocs. À la fin du mois de juillet, 85% du hashrate avait adopté des taux de frais minimums plus bas et les transactions à faible taux de frais se propageaient organiquement (bien que de manière peu fiable) sur le réseau en raison de la configuration manuelle de limites inférieures par les opérateurs de nœuds. À la mi-août, plus de 30% des transactions confirmées payaient des taux de frais inférieurs à 1 sat/vbyte. Les développeurs du protocole Bitcoin ont observé que le taux élevé de transactions à faible taux de frais manquantes [provoquait une diminution des taux de reconstruction de blocs compacts]]0xb10c delving et fait une proposition d’ajustement du taux minimal de relais par défaut. La version 29.1 de Bitcoin Core a réduit le taux minimal de relais par défaut à 0,1  sat/vbyte au début de septembre.

  • ● Partage de modèles de blocs entre pairs : Anthony Towns a proposé une méthode pour améliorer l’efficacité de la reconstruction de blocs compacts dans un environnement où les politiques de mempool des pairs divergent. La proposition permettrait aux nœuds complets d’envoyer des modèles de blocs à leurs pairs, qui à leur tour, mettraient en cache ces transactions qui seraient autrement rejetées par leurs politiques de mempool. Le modèle fourni contient des identifiants de transaction encodés dans le même format utilisé par le relai de blocs compacts.

    Plus tard, en août, Towns a ouvert un BIPs #1937 pour discuter formellement de la proposition de partage de modèles de blocs. Au cours de la discussion, plusieurs développeurs ont exprimé des préoccupations concernant la vie privée et le potentiel de fingerprinting des nœuds. En octobre, Towns a décidé de déplacer le brouillon vers le dépôt Bitcoin Inquisition Numbers and Names Authority (BINANA) pour aborder ces considérations et affiner le document. Le brouillon a reçu le code BIN-2025-0002.

  • ● Fuzzing différentiel des implémentations de Bitcoin et LN : Bruno Garcia a donné une mise à jour sur les progrès et résultats obtenus par bitcoinfuzz, une bibliothèque pour effectuer des tests de fuzzing sur les implémentations et bibliothèques de Bitcoin et Lightning. En utilisant la bibliothèque, les développeurs ont signalé plus de 35 bugs dans des projets liés à Bitcoin, tels que btcd, rust-bitcoin, rust-miniscript, LND, et plus encore.

    Garcia a également souligné l’importance du fuzzing différentiel dans l’écosystème. Les développeurs sont capables de découvrir des bugs dans des projets qui n’implémentent pas du tout le fuzzing, de repérer des divergences entre les implémentations de Bitcoin, et de trouver des lacunes dans les spécifications de Lightning.

    Enfin, Garcia a encouragé les mainteneurs à intégrer davantage de projets dans bitcoinfuzz, en élargissant le support pour le fuzzing différentiel, et a fourni des orientations possibles pour le développement futur du projet.

Résumé 2025 : Stratum v2

Stratum v2 est un protocole de minage conçu pour remplacer le protocole Stratum original utilisé entre les mineurs et les pools de minage. L’un de ses principaux avantages est qu’il peut permettre aux membres individuels du pool de choisir quelles transactions inclure dans leurs blocs, améliorant la résistance à la censure de Bitcoin en distribuant la sélection des transactions à de nombreux mineurs indépendants.

Tout au long de 2025, Bitcoin Core a reçu plusieurs mises à jour pour mieux soutenir les implémentations de Stratum v2. Certaines améliorations plus tôt dans l’année étaient concentrées sur les RPCs de minage, les mettant à jour avec les champs nBits, target, et next, utiles pour construire et valider des modèles de blocs.

Le travail le plus significatif s’est concentré sur l’interface de communication inter-processus (IPC) expérimentale de Bitcoin Core, qui permet à un service Stratum v2 externe d’interagir avec la validation de blocs de Bitcoin Core sans utiliser l’interface JSON-RPC plus lente. Une nouvelle méthode waitNext() a été introduite à l’interface BlockTemplate qui retourne un nouveau modèle uniquement lorsque le sommet de la chaîne change ou lorsque les frais de mempool augmentent significativement, réduisant les recalculs inutiles de génération de modèles. checkBlock a ensuite été ajouté, permettant aux pools de valider les modèles fournis par les mineurs via IPC. IPC a également été activé par défaut, et le nouveau bitcoin-node ainsi que d’autres binaires multiprocessus ont été ajoutés aux versions de publication. Un exécutable wrapper bitcoin a été ajouté pour découvrir facilement et lancer un nombre croissant de binaires, et une mise à jour a implémenté la sélection automatique du multiprocessus, éliminant le besoin du drapeau de démarrage -m. Les améliorations de l’IPC de cette année ont été conclues par la réduction de la consommation CPU pour la journalisation multiprocessus et en assurant que les blocs soumis via IPC ont leur engagement de témoin revalidé.

Bitcoin Core 30.0, sorti en octobre, était la première version à inclure l’interface expérimentale de minage IPC, précédemment introduite l’année dernière.

En juin, StarkWare a démontré un client Stratum v2 modifié utilisant des preuves STARK pour prouver que les frais d’un bloc appartiennent à un modèle valide sans révéler les transactions du bloc. Deux nouvelles pool de minage basées sur Stratum v2 ont également été lancées : Hashpool, qui représente les parts de minage sous forme de jetons ecash, et DMND, qui est passé du minage solo au minage en pool.

Septembre

  • ● Détails sur la conception de Simplicity : Après la sortie de Simplicity sur le Liquid Network, Russell O’Connor a fait trois publications sur Delving Bitcoin pour discuter de la philosophie et de la conception derrière le langage :

    • Partie I examine les trois principales formes de composition pour transformer des opérations basiques en opérations complexes.

    • Partie II plonge dans les combinatoires du système de types de Simplicity et les expressions de base.

    • Partie III explique comment construire des opérations logiques à partir de bits jusqu’aux opérations cryptographiques en utilisant uniquement des combinatoires de calcul de Simplicity.

    Depuis septembre, deux autres publications ont été publiées sur Delving Bitcoin, Partie IV, discutant des effets de bord, et Partie V, traitant des programmes et des adresses.

  • ● Partitionnement et attaques par éclipse utilisant l’interception BGP : Cedarctic a publié sur Delving Bitcoin à propos des failles dans le Protocole de Passerelle Frontière (BGP) qui pourraient être utilisées pour empêcher les nœuds complets de pouvoir se connecter à des pairs honnêtes, permettant potentiellement des partitions de réseau ou des attaques par éclipse. Plusieurs atténuations ont été décrites par Cedarctic, avec d’autres développeurs dans la discussion décrivant d’autres atténuations et moyens de surveiller l’attaque.

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

  • ● BDK wallet-1.0.0 a marqué la première sortie majeure de cette bibliothèque, où le crate bdk original a été renommé en bdk_wallet avec une API stable et des modules de couche inférieure ont été extraits dans leurs propres crates.

  • ● LDK v0.1 a ajouté le support pour les deux côtés des protocoles de négociation d’ouverture de canal LSPS, BIP353 de résolution de noms lisibles par l’homme, et réduit les coûts de frais onchain lors de la résolution de multiples HTLCs pour une fermeture forcée de canal unique.

  • ● Core Lightning 25.02 a ajouté le support pour le stockage de pairs, désactivé par défaut.

  • ● Eclair v0.12.0 a ajouté le support pour la création et la gestion des offres BOLT12, un nouveau protocole de fermeture de canal qui supporte RBF, et le support pour le stockage de petites quantités de données pour les pairs à travers le stockage de pairs.

  • ● BTCPay Server 2.1.0 a ajouté plusieurs améliorations pour RBF et CPFP pour l’augmentation des frais, un meilleur flux pour multisig lorsque tous les signataires utilisent BTCPay Server, et a effectué quelques changements majeurs pour les utilisateurs de certains altcoins.

  • ● Bitcoin Core 29.0 a remplacé la fonctionnalité UPnP (responsable en partie de plusieurs vulnérabilités de sécurité passées) par une option NAT-PMP, amélioré la récupération des parents de transactions orphelines pour le relai de paquets, amélioré l’évitement de timewarp pour les mineurs, et migré le système de construction de automake à cmake.

  • ● LND 0.19.0-beta a ajouté un nouveau bumping de frais basé sur RBF pour les fermetures coopératives.

  • ● Core Lightning 25.05 a introduit un support expérimental pour le splicing compatible avec Eclair, et activé le stockage de pairs par défaut.

  • ● BTCPay Server 2.2.0 a ajouté le support pour les politiques de portefeuille et miniscript.

  • ● Core Lightning v25.09 a ajouté le support à la commande xpay pour payer les adresses BIP353 et les offres.

  • ● Eclair v0.13.0 a introduit une mise en œuvre initiale de canaux simple taproot, des améliorations au splicing basées sur les mises à jour récentes des spécifications, et un meilleur support BOLT12.

  • ● Bitcoin Inquisition 29.1 a ajouté le support pour OP_INTERNALKEY, un opcode faisant partie de plusieurs propositions de covenants.

  • ● Bitcoin Core 30.0 a rendu standard plusieurs sorties de porteur de données (OP_RETURN), augmenté la datacarriersize par défaut à 100 000, fixé un taux de frais minimum de relais par défaut de 0.1 sat/vbyte, ajouté une interface de minage IPC expérimentale pour les intégrations Stratum v2, et retiré le support pour la création ou le chargement de portefeuilles hérités. Les portefeuilles hérités peuvent être migrés vers le format de portefeuille descripteur.

  • ● Core Lightning v25.12 a ajouté les phrases de semence mnémonique BIP39 comme nouvelle méthode de sauvegarde par défaut et un support expérimental pour les canaux JIT.

  • ● LDK 0.2 a ajouté le support pour le splicing (expérimental), servant et payant des factures statiques pour les paiements asynchrones, et des canaux d’engagement sans frais utilisant les ancres éphémères.

Octobre

  • ● Discussions sur les données arbitraires : La conversation en octobre a revisité des questions de longue date sur l’intégration de données arbitraires dans les transactions Bitcoin et les limites de l’utilisation de l’ensemble UTXO à cet effet. Une analyse a examiné les contraintes théoriques sur le stockage des données dans les UTXOs, même sous un ensemble restrictif de règles de transaction Bitcoin.

    Les discussions subséquentes tout au long de l’année se sont concentrées sur la question de savoir si les restrictions de consensus sur les transactions portant des données devraient être considérées.

  • ● Résultats de simulation et mises à jour sur l’atténuation du brouillage de canal : Carla Kirk-Cohen, en collaboration avec Clara Shikhelman et elnosh, a publié les résultats de la simulation de brouillage de Lightning pour leur algorithme de réputation mis à jour. Les mises à jour comprenaient le suivi de la réputation pour les canaux sortants et le suivi des limitations de ressources des canaux entrants. Avec ces nouvelles mises à jour, ils ont trouvé que cela protège toujours contre les attaques de ressources et de puits. Après ce cycle de mises à jour et de simulations, ils estiment que l’atténuation des attaques de brouillage de canal a atteint un point où elle est suffisante pour une mise en œuvre.

Novembre

  • ● Comparaison de la performance de la validation de signature ECDSA dans OpenSSL vs. libsecp256k1 : Dix ans après que Bitcoin Core soit passé d’OpenSSL à libsecp256k1, Sebastian Falbesoner a publié une analyse comparative de la performance des deux bibliothèques cryptographiques pour la validation de signature. Libsecp256k1 a été créé en 2015 spécifiquement pour Bitcoin Core, et était déjà entre 2,5 et 5,5 fois plus rapide à l’époque. Falbesoner a trouvé que l’écart s’est depuis élargi à plus de 8x, car libsecp256k1 a continué à s’améliorer tandis que la performance de secp256k1 d’OpenSSL est restée statique, ce qui n’est pas surprenant étant donné la pertinence limitée de la courbe en dehors de Bitcoin.

    Dans la discussion, le créateur de libsecp256k1, Pieter Wuille, note que les benchmarks ont des biais inhérents : toutes les versions ont été testées sur du matériel moderne et des compilateurs, mais les optimisations historiques ciblaient le matériel et les compilateurs qui existaient à l’époque.

  • ● Modélisation des taux d’obsolescence par délai de propagation et centralisation de l’exploitation minière : Antoine Poinsot a publié sur Delving Bitcoin en analysant comment les délais de propagation des blocs avantagent systématiquement les mineurs plus importants. Il a modélisé deux scénarios dans lesquels le bloc A devient obsolète. Dans le premier, un bloc concurrent B est trouvé avant A et se propage en premier. Dans le second, B est trouvé peu après A, mais le même mineur trouve également le bloc suivant. Le premier scénario est plus probable, suggérant que les mineurs bénéficient plus d’entendre rapidement les blocs des autres que de diffuser les leurs.

    Poinsot a montré que les taux d’obsolescence augmentent avec le délai de propagation et affectent de manière disproportionnée les mineurs plus petits. Il a trouvé qu’avec un délai de propagation de 10 secondes, une opération de 5 EH/s générant 91 millions de dollars annuellement pourrait gagner environ 100 000 dollars de revenus supplémentaires en se connectant au plus grand pool plutôt qu’au plus petit. Étant donné que l’exploitation minière fonctionne avec des marges réduites, de petites différences de revenus peuvent se traduire par des impacts significatifs sur les profits.

  • ● BIP3 et le processus BIP : En 2025, le travail sur une proposition de mise à jour du processus BIP a avancé de manière significative. BIP3 a été attribué d’un numéro en janvier, publié en février, et est passé à l’état Proposé en avril. Une révision supplémentaire a été suivie de quelques mises à jour, dans lesquelles les Expressions de Licence SPDX ont été introduites, certains en-têtes de Préambule ont été mis à jour, et plusieurs clarifications ont été intégrées dans les propositions. En novembre, Murch a proposé d’activer la proposition, en demandant aux lecteurs de revoir la proposition dans les quatre semaines suivantes et de commenter si BIP3 devrait être activé. Une série de révisions subséquentes a résulté en quelques améliorations supplémentaires et la révocation de directives controversées interdisant l’utilisation des LLMs dans la rédaction des BIPs. Alors que l’année se termine, toutes les révisions ont été prises en compte, et BIP3 est à la recherche d’un consensus général pour une nouvelle activation.

  • ● Introduction de l’API C au noyau Bitcoin : Bitcoin Core #30595 a introduit un en-tête C qui sert d’API pour bitcoinkernel, permettant aux projets externes d’interfacer avec la logique de validation des blocs et l’état de la chaîne de Bitcoin Core via une bibliothèque C réutilisable. Actuellement, elle est limitée aux opérations sur les blocs et possède une parité de fonctionnalités avec le désormais obsolète libbitcoin-consensus (voir le Bulletin #288).

    Les cas d’utilisation pour bitcoinkernel incluent des implémentations alternatives de nœuds, un constructeur d’index de serveur Electrum, un scanner de paiements silencieux, un outil d’analyse de blocs, et un accélérateur de validation de scripts, entre autres. Plusieurs liaisons linguistiques sont en développement, y compris pour Rust, Go, JDK, C#, et Python.

Résumé 2025 : Bitcoin Optech

Pour la huitième année d’Optech, nous avons publié 50 bulletins hebdomadaires et ce spécial Revue de l’Année. Au total, Optech a publié plus de 80 000 mots en anglais sur la recherche et le développement logiciel Bitcoin cette année, l’équivalent approximatif d’un livre de 225 pages.

Chaque bulletin et article de blog a été traduit en chinois, en français et en japonais, avec d’autres langues également traduites, pour un total de plus de 150 traductions en 2025.

De plus, chaque bulletin de cette année a été accompagnée d’un épisode de podcast, totalisant plus de 60 heures sous forme audio et plus de 500 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 en 2025 :

  • 0xB10C
  • Abubakar Sadiq Ismail (x3)
  • Alejandro De La Torre
  • Alex Myers
  • Andrew Toth
  • Anthony Towns
  • Antoine Poinsot (x5)
  • Bastien Teinturier (x3)
  • Bob McElrath
  • Bram Cohen
  • Brandon Black
  • Bruno Garcia
  • Bryan Bishop
  • Carla Kirk-Cohen (x2)
  • Chris Stewart
  • Christian Kümmerle
  • Clara Shikhelman
  • Constantine Doumanidis
  • Dan Gould
  • Daniela Brozzoni (x2)
  • Daniel Roberts
  • Davidson Souza
  • David Gumberg
  • Elias Rohrer
  • Eugene Siegel (x2)
  • Francesco Madonna
  • Gloria Zhao (x2)
  • Gregory Sanders (x2)
  • Hunter Beast
  • Jameson Lopp (x2)
  • Jan B
  • Jeremy Rubin (x2)
  • Jesse Posner
  • Johan Halseth
  • Jonas Nick (x4)
  • Joost Jager (x2)
  • Jose SK
  • Josh Doman (x2)
  • Julian
  • Lauren Shareshian
  • Liam Eagen
  • Marco De Leon
  • Matt Corallo
  • Matt Morehouse (x7)
  • Moonsettler
  • Naiyoma
  • Niklas Gögge
  • Olaoluwa Osuntokun
  • Oleksandr Kurbatov
  • Peter Todd
  • Pieter Wuille
  • PortlandHODL
  • Rene Pickhardt
  • Robin Linus (x3)
  • Rodolfo Novak
  • Ruben Somsen (x2)
  • Russell O’Connor
  • Salvatore Ingala (x4)
  • Sanket Kanjalkar
  • Sebastian Falbesoner (x2)
  • Sergi Delgado
  • Sindura Saraswathi (x2)
  • Sjors Provoost (x2)
  • Steve Myers
  • Steven Roose (x3)
  • Stéphan Vuylsteke (x2)
  • supertestnet
  • Tadge Dryja (x3)
  • TheCharlatan (x2)
  • Tim Ruffing
  • vnprc
  • Vojtěch Strnad
  • Yong Yu
  • Yuval Kogman
  • ZmnSCPxj (x3)

Optech a eu la chance et la gratitude de recevoir une autre contribution de 20 000 USD de la part de la Human Rights Foundation. Les 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 livraison de contenu technique à la communauté Bitcoin.

Un remerciement spécial

Après avoir contribué en tant qu’auteur principal pour 376 bulletins Bitcoin Optech consécutifs, Dave Harding a pris du recul par rapport à ses contributions régulières cette année. Nous ne pouvons pas assez remercier Harding pour avoir ancré le bulletin pendant huit ans et pour toute l’éducation, l’élucidation et la compréhension de Bitcoin qu’il a apportées à la communauté. Nous lui sommes éternellement reconnaissants et lui souhaitons tout le meilleur.

Décembre

  • ● Splicing : En décembre, LDK 0.2 a été publié avec un support expérimental du splicing, rendant la fonctionnalité disponible sur trois principales implémentations de Lightning : LDK, Eclair et Core Lightning. Le splicing permet aux nœuds d’ajouter ou de retirer des fonds d’un canal sans le fermer.

    Cela a conclu une année de progrès significatifs vers la fonctionnalité de splicing de LN. Eclair a ajouté le support du splicing sur les canaux publics en février et le splicing dans les canaux taproot simples en août. Pendant ce temps, Core Lightning a finalisé l’interopérabilité avec Eclair en mai et l’a expédié dans Core Lightning 25.05.

    Tout au long de l’année, toutes les pièces nécessaires pour l’implémentation de LDK ont été ajouté, incluant le support de l’épissure en août, intégrant l’épissure avec le protocole de quiescence en septembre, et expédiant de nombreux raffinements supplémentaires avant la sortie de la version 0.2.

    Les équipes de mise en œuvre ont également coordonné sur les détails de la spécification, tels que l’augmentation du délai avant de marquer un canal comme fermé pour permettre la propagation de l’épissure (augmenté de 12 à 72 blocs par BOLTs #1270) et la logique de reconnexion pour l’état de l’épissure synchronisé par BOLTs #1289.

    Cependant, la principale spécification de l’épissure reste non fusionnée à la fin de l’année, avec des mises à jour toujours attendues et des problèmes de compatibilité croisée continuant à être résolus.

Nous remercions tous les contributeurs Bitcoin mentionné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. La bulletin Optech reprendra sa publication régulière le vendredi à partir du 2 janvier.