Cette édition spéciale du bulletin Optech résume les principaux développements de Bitcoin au cours de l’année 2021. Ceci est la suite de nos résumés de 2018, 2019, et 2020.

Sommaire

Janvier

Après des années de discussion, le mois de janvier a vu la première publication d’une version de Bitcoin Core supportant les signets, après le support de C-Lightning et le support de LND. Les signets sont des réseaux de test que chacun peut utiliser pour simuler le réseau principal de Bitcoin (mainnet), tel qu’il existe aujourd’hui ou tel qu’il pourrait exister avec certains changements (comme l’activation d’un embranchement convergent). La plupart des logiciels qui mettent en œuvre des signets prennent également en charge un signet par défaut qui constitue un moyen particulièrement pratique pour que les logiciels développés par différentes équipes soient testés dans un environnement sûr, aussi proche que possible de celui qu’ils rencontreront lorsque de l’argent réel sera en jeu. L’ajout de réorganisations délibérées de la chaîne de blocs au réseau de signets par défaut de Bitcoin Core, afin d’aider les développeurs à tester leurs logiciels face à cette catégorie de problèmes, a également été discuté cette année.

Un projet de BIP pour bech32m a également été annoncé en janvier. Les adresses bech32m sont une légère modification des adresses bech32 qui les rendent sûres pour une utilisation avec taproot et les futures extensions du protocole. Plus tard dans l’année, une page Wiki Bitcoin a été mise à jour pour suivre l’adoption des adresses bech32m par les portefeuilles et les services.

Une autre première version d’un nouveau protocole était les messages en oignon et le protocole d’offres. Les messages en oignon permettent à un nœud LN d’envoyer un message à un autre nœud d’une manière qui minimise la surcharge par rapport à l’envoi de messages basés sur le HTLC. Les offres utilisent les messages en oignon pour permettre à un nœud d’offrir de payer un autre nœud, permettant au nœud récepteur de renvoyer une facture détaillée et d’autres informations nécessaires. Les messages en oignon et les offres resteront des projets de spécifications jusqu’à la fin de l’année, mais ils feront l’objet de développements supplémentaires, notamment une proposition visant à les utiliser pour réduire l’impact des paiements bloqués.

Février

Les contributeurs de Bitcoin ont fait le point sur l’état des recherches concernant un algorithme amélioré de création et de vérification des signatures, puis ont utilisé leurs recherches pour produire une variante comportant des améliorations supplémentaires. Lorsqu’il a été implémenté dans libsecp256k1 (1, 2) et plus tard dans Bitcoin Core, il a permis de réduire le temps nécessaire à la vérification des signatures d’environ 10 %—une amélioration significative pour la vérification des quelque milliards de signatures de la chaîne de blocs de Bitcoin. Plusieurs cryptographes ont travaillé pour s’assurer que ce changement était mathématiquement solide et sûr à utiliser. Cette modification permet également d’accélérer considérablement la création de signatures sécurisées sur des dispositifs de signature matériels de faible puissance.

Attaques par brouillage de canaux, un problème connu de LN depuis 2015, a fait l’objet de discussions continues tout au long de l’année, avec une variété de possibilités et de solutions discutées. Malheureusement, aucune solution largement acceptée n’a été trouvée et le problème n’a pas été atténué à la fin de l’année.

Illustration of jamming attacks

Mars

D’importantes discussions en mars ont été consacrées à l’analyse du risque d’attaques d’ordinateurs quantiques sur Bitcoin, en particulier pour le cas où taproot s’activerait et deviendrait largement utilisé. L’une des caractéristiques originales de Bitcoin, le hachage de la clé publique—vraisemblablement ajouté pour raccourcir les adresses Bitcoin—a également rendu plus difficile le vol de fonds d’un nombre limité d’utilisateurs en cas d’avancée majeure et soudaine de l’informatique quantique. Taproot ne fournit pas cette fonctionnalité et au moins un développeur s’est inquiété du fait que cela créait un risque déraisonnable. Un grand nombre de contre-arguments ont été présentés et le soutien de la communauté pour taproot semble être inchangé.

Sommaire 2021
Activiation de Taproot

Fin 2020, une implémentation de l’embranchement convergent taproot contenant le support des signatures de schnorr et tapscript avait été fusionnée dans Bitcoin Core. Ceci a largement achevé le travail des développeurs de protocoles ; il appartient maintenant à la communauté d’activer taproot si elle le souhaite, et aux développeurs de portefeuilles de commencer à le prendre en charge, ainsi que les technologies connexes comme les adresses bech32m.

  • ● Janvier a commencé avec la sortie de Bitcoin Core 0.21.0, qui était la première version à prendre en charge les signets, y compris le signet par défaut où taproot avait été activé—donnant aux utilisateurs et aux développeurs un endroit facile pour commencer les tests.

  • ● Février a vu la première des nombreuses réunions prévues dans le canal IRC ##taproot-activation, qui allait devenir le principal centre de discussion entre les développeurs, les utilisateurs et les mineurs sur la façon d’activer taproot.

  • ● Mars a commencé avec de nombreux participants à la discussion qui ont provisoirement accepté d’essayer une approche d’activation particulière appelée speedy trial, qui a été conçue pour recueillir un retour d’information rapide de la part des mineurs, mais aussi pour donner aux utilisateurs suffisamment de temps pour mettre à jour leur logiciel pour l’application de taproot. Speedy trial est ensuite devenu le mécanisme utilisé pour activer taproot.

    Alors que des discussions sur l’activation étaient en cours, une dernière discussion a porté sur l’une de ses décisions de conception, l’utilisation de clés publiques nues, qui, selon certains, pourrait accroître le risque de vol des fonds des utilisateurs par les futurs ordinateurs quantiques. De nombreux développeurs ont fait valoir que ces inquiétudes étaient injustifiées ou, du moins, exagérées.

    En mars également, Bitcoin Core a fusionné la prise en charge du BIP350, ce qui lui permet de payer les adresses bech32m. Cette légère variation des adresses bech32 qui sont utilisées pour les paiements aux adresses de la version originale de segwit corrige un bogue qui aurait pu faire perdre de l’argent aux utilisateurs de taproot dans certains cas très rares. (Les sorties segwit originales créées à partir des adresses bech32 sont sûres et non affectées par le bogue).

  • ● Avril a presque vu les progrès de l’activation dérailler alors que les développeurs du protocole et certains utilisateurs débattaient des mérites de deux versions légèrement différentes du mécanisme d’activation de speedy trial. Cependant, les auteurs des différentes implémentations des deux versions différentes sont parvenus à un compromis qui a permis la publication d’une version de Bitcoin Core avec un mécanisme et des paramètres d’activation.

  • ● Mai C’est à ce moment-là que les mineurs ont été capables de commencer à signaler qu’ils étaient prêts à appliquer taproot et qu’un site Web permettant de suivre la progression de la signalisation est devenu populaire.

  • ● Juin a vu les mineurs verouiller taproot, s’engageant à appliquer son activation environ six mois plus tard au bloc 709,632. Cela signifie qu’il était temps pour les développeurs de portefeuilles et les autres développeurs d’infrastructures de mettre plus d’attention à adapter leur logiciel pour taproot, ce que beaucoup d’entre eux ont fait. De plus, une proposition a été faite pour permettre aux portefeuilles taproot onchain de contribuer facilement à la confidentialité des portefeuilles utilisant divers protocoles contractuels comme LN et coinswaps. Optech a également commencé sa série Preparing for Taproot.

  • ● Juillet a rencontré une page du Bitcoin Wiki consacrée au suivi du support du format d’adresse bech32m nécessaire aux portefeuilles pour pouvoir utiliser taproot après son activation. De nombreux développeurs de portefeuilles et de services se sont montrés à la hauteur de la situation et ont assuré qu’ils seraient prêts à permettre à quiconque d’utiliser taproot dès son activation. D’autres propositions d’embranchement convergent ont été mises à jour pour utiliser taproot ou tirer les leçons de son activation.

  • ● Août a été tranquille pour le développement de taproot, bien que quelques documentations liées à taproot ont été écrites.

  • ● Septembre a vu le logiciel pour les commerçants open source le plus populaire de Bitcoin ajouter le support pour taproot avant son activation prévue. Il a également vu la proposition d’un nouvel opcode qui ferait un usage particulier des fonctionnalités de taproot pour permettre des conditions de dépense basées sur des scripts.

  • ● Octobre a commencé avec une activité de développement renouvelée alors que l’activation de taproot approchait. Le BIP de Taproot a été mis à jour avec des vecteurs de test étendus pour aider les développeurs de portefeuilles et d’infrastructures à vérifier leurs implémentations.

  • ● Novembre a célébré l’activation de taproot. Il y a eu une certaine confusion au départ, car les mineurs du bloc 709,632 et de plusieurs blocs ultérieurs n’ont pas inclus de transactions de dépense avec taproot. Cependant, grâce au travail de plusieurs développeurs et administrateurs de pools de minage, la plupart des blocs minés les jours suivants étaient prêts à contenir des transactions de type taproot-spending. Développement et test du logiciel taproot-ready ont suivis.

  • ● Decembre a vu Bitcoin Core fusionner une PR qui permettrait aux portefeuilles avec descripteurs de créer des adresses bech32m pour recevoir des paiements taproot. Les développeurs de LN ont également discuté de l’utilisation des fonctionnalités de taproot.

Malgré des complications dans le choix du mécanisme d’activation de taproot et une légère confusion immédiatement après son activation, les dernières étapes de l’ajout à Bitcoin du support de l’embranchement convergent taproot semblent s’être bien déroulées. Ce n’est pas la fin de l’histoire pour taproot. Optech s’attend à continuer à passer beaucoup de temps à écrire à son sujet dans les années à venir, alors que les développeurs de portefeuilles et d’infrastructures commencent à utiliser ses nombreuses fonctionnalités.

Avril

LND a ajouté le support en avril pour effectuer des Paiements Atomiques à Multiples Chemins (AMP), également appelés originellement AMPs car ils sont décrits plus tôt que les Paiements Simplifiés à Multiples Chemins (SMP) que toutes les implémentations majeures de LN supportent actuellement. Les AMP ont un avantage en matière de confidentialité par rapport aux SMP et garantissent également que le récepteur a reçu l’ensemble des fonds avant de finaliser le paiement. Leur inconvénient est qu’ils ne produisent pas de preuve cryptographique du paiement. LND les a implémentés pour les utiliser avec les paiements spontanés qui, fondamentalement, ne peuvent pas fournir de preuve de paiement, éliminant ainsi le seul inconvénient significatif des AMP.

Mai

Une divergence entre les spécifications du BIP125 de remplacement des transactions topic rbf et la mise en œuvre dans Bitcoin Core a été divulguée en mai. Cela n’a pas mis de bitcoins en danger, pour autant que nous le sachions, mais cela a donné lieu à plusieurs discussions sur les risques encourus par les utilisateurs de protocoles contractuels (tels que LN) en raison du comportement inattendu du relais de transaction.

En mai également, le projet C-Lightning a fusionné un plugin pour la gestion des canaux à financement bipartite—des canaux où les deux parties peuvent fournir un certain montant du financement initial. En plus du travail antérieur sur le financement bipartite fusionné cette année, cela permet à la partie qui initie l’ouverture du canal non seulement de dépenser les fonds par le canal mais aussi de les recevoir dans l’état initial du canal. Cette capacité initiale à recevoir des fonds rend le financement bipartite particulièrement utile pour les commerçants dont l’utilisation principale de LN est de recevoir des paiements au lieu de les envoyer.

Sommaire 2021
Mises à jour et version candidate

Juin

Une nouvelle analyse discutée en juin décrit une autre façon pour les mineurs de sélectionner les transactions qu’ils souhaitent inclure dans les blocs qu’ils créent. La nouvelle méthode devrait augmenter légèrement les revenus des mineurs à court terme. À long terme, si cette technique est adoptée par les mineurs, les portefeuilles qui en ont connaissance pourront collaborer lors de l’utilisation de CPFP pour augmenter les frais d’une transaction, ce qui augmentera l’efficacité de cette technique.

Une autre tentative pour rendre le remplacement des frais plus efficace a été une proposition pour permettre à toute transaction non confirmée d’être remplacée avec des frais plus élevés (RBF) dans Bitcoin Core—et pas seulement celles qui ont choisi d’autoriser le remplacement en utilisant BIP125. Cela pourrait aider à résoudre certains problèmes liés au remplacement des frais dans les protocoles multipartites et également améliorer la confidentialité en permettant à davantage de transactions d’utiliser des paramètres uniformes. En ce qui concerne la confidentialité, une proposition distincte a suggéré que les portefeuilles créant des dépenses taproot définissent une valeur nSequence par défaut même s’ils n’ont pas besoin des fonctionnalités offertes par les valeurs de séquence appliquées par consensus du BIP68 ; cela permettrait aux transactions créées par des logiciels qui ont besoin d’utiliser BIP68 de se fondre dans la masse des transactions plus courantes. Aucune des deux propositions n’a semblé faire beaucoup de progrès malgré quelques objections significatives.

Le mois de juin a également vu la fusion de la première PR d’une série mettant en œuvre l’acceptation des paquets mempool dans Bitcoin Core, la première étape vers le relais de paquets. Le relais de paquets permettra aux nœuds de relais et aux mineurs de traiter des paquets de transactions liées comme s’il s’agissait d’une seule transaction à des fins de gestion des frais. Un paquet pourrait contenir une transaction parent avec un faible taux de frais et une transaction enfant avec un taux de frais élevé ; la rentabilité de l’exploitation de la transaction enfant inciterait les mineurs à exploiter également la transaction parent. Bien que le minage de paquets ait été implémenté dans Bitcoin Core depuis 2016, il n’y avait jusqu’à présent aucun moyen pour les nœuds de relayer les transactions sous forme de paquets, ce qui signifie que les transactions parentales à faible taux de frais pouvaient ne pas atteindre les mineurs pendant les périodes à haut taux de frais, même si elles ont des enfants à haut taux de frais. Cela rend l’utilisation de CPFP peu fiable pour les protocoles de contrat utilisant des transactions présignées, comme LN. Le relais de paquet espère résoudre ce problème de sécurité clé.

Une idée initialement proposée en 2019 pour LN a connu un regain de vie en juin. L’idée originale de fast forward décrivait comment un porte-monnaie LN pouvait recevoir ou relayer un paiement avec moins d’allers-retours sur le réseau, réduisant ainsi la bande passante du réseau et la latence du paiement. L’idée a été élargie cette année pour décrire comment un porte-monnaie LN pourrait recevoir plusieurs paiements sans apporter sa clé de signature en ligne pour chaque paiement, ce qui facilite le maintien de cette clé de signature en sécurité.

Juillet

Après des années de discussion et de développement, la première implémentation d’un système décentralisé d’annonces de liquidité a été fusionnée dans une implémentation LN. La proposition d’annonce de liquidité encore à l’état de projet permet à un nœud d’utiliser le protocole de gossip LN pour annoncer sa volonté de louer ses fonds pour une période de temps, donnant aux autres noeuds la possibilité d’acheter une capacité entrante qui leur permet de recevoir des paiements instantanés. Un nœud qui voit l’annonce peut simultanément payer et recevoir la capacité entrante en utilisant l’ouverture d’un canal à financement bipartite. Bien qu’il n’y ait aucun moyen d’imposer que le nœud annonceur achemine effectivement les paiements, la proposition intègre une proposition antérieure (également utilisée ultérieurement dans Lightning Pool) qui empêche l’annonceur d’utiliser son argent à d’autres fins jusqu’à la fin de la période de location convenue. Cela signifie que le refus d’acheminer les paiements n’apporterait aucun avantage mais priverait le nœud annonceur de la possibilité de gagner des frais d’acheminement.

Trois ans après avoir été proposés pour la première fois pour Bitcoin Core, des projets de BIP ont été créés pour les descripteurs de script de sortie. Les descripteurs sont des chaînes de caractères qui contiennent toutes les informations nécessaires pour permettre à un portefeuille ou à un autre programme de suivre les paiements effectués ou dépensés à partir d’un script particulier ou d’un ensemble de scripts apparentés (c’est-à-dire une adresse ou un ensemble d’adresses apparentées, comme dans un portefeuille HD). Les descripteurs se combinent bien avec miniscript en permettant à un porte-monnaie de gérer le suivi et la signature pour une plus grande variété de scripts. Ils se combinent également bien avec PSBT pour permettre au porte-monnaie de déterminer les clés qu’il contrôle dans un script multisig. À la fin de l’année, Bitcoin Core a fait des portefeuilles basés sur des descripteurs son paramétrage par défaut pour les portefeuilles nouvellement créés.

Une façon courante d’ouvrir des canaux LN qui n’avaient jamais fait partie du protocole LN a commencé à être spécifiée en juillet. Les ouvertures de canaux 0-conf, également appelés canaux turbo, sont de nouveaux canaux à financement unique où le financeur donne une partie ou la totalité de ses fonds initiaux à la partie acceptante. Ces fonds ne sont pas sécurisés tant que la transaction d’ouverture de canal n’a pas reçu un nombre suffisant de confirmations, de sorte qu’il n’y a aucun risque que l’accepteur dépense une partie de ces fonds à travers le financeur en utilisant le protocole standard LN. Par exemple, Alice a plusieurs BTC sur un compte chez le dépositaire de Bob. Alice demande à Bob d’ouvrir un nouveau canal en lui versant 1,0 BTC. Parce que Bob a confiance en lui pour ne pas dépenser deux fois le canal qu’il vient d’ouvrir, il peut permettre à Alice d’envoyer 0,1 BTC par son nœud à un tiers Carol avant même que la transaction d’ouverture du canal n’ait reçu une seule confirmation. La spécification du comportement devrait contribuer à améliorer l’interopérabilité entre les nœuds LN et les marchands qui offrent ce service.

Zero-conf channel illustration

Deux propositions connexes de nouveaux types de hachage de signature (sighash) ont été combinées dans le BIP118. SIGHASH_NOINPUT, proposé en 2017 et partiellement basé sur des propositions précédentes remontant à une décennie, a été remplacé par SIGHASH_ANYPREVOUT et SIGHASH_ANYPREVOUTANYSCRIPT d’abord proposé en 2019. Les nouveaux types de sighash permettront aux protocoles hors chaîne tels que LN et les coffres de réduire le nombre d’états intermédiaires qu’ils doivent conserver, ce qui réduira considérablement les besoins de stockage et la complexité. Pour les protocoles multipartites, les avantages peuvent être encore plus importants en éliminant le nombre d’états différents qui doivent être générés en premier lieu.

Août

Les bons de fidélité sont une idée décrite au moins depuis 2010 pour verrouiller les bitcoins pendant une période de temps afin de créer un coût pour les mauvais comportements dans les systèmes tiers. Comme les bitcoins ne peuvent pas être réutilisés avant l’expiration du verrouillage, les utilisateurs de l’autre système qui sont bannis ou autrement pénalisés pendant la période de verrouillage ne peuvent pas utiliser les mêmes bitcoins pour créer une nouvelle identité virtuelle. En août, JoinMarket a mis en production la première utilisation à grande échelle et décentralisée des bons de fidélité. Quelques jours après le lancement, plus de 50 BTC avaient été verrouillés (d’une valeur de plus de 2 millions de dollars américains à l’époque).

Une nouvelle variante d’algorithme de recherche de chemin pour LN a été discutée en août. Les partisans de cette technique pensaient qu’elle serait plus efficace si les nœuds d’acheminement ne facturaient qu’un pourcentage du montant acheminé sans facturer un minimum de frais de base sur chaque paiement. D’autres étaient d’un avis différent. D’ici la fin de l’année, une variation de cette technique sera implémentée dans C-Lightning.

Sommaire 2021
Bitcoin Optech

Au cours de la quatrième année d’Optech, nous avons publié 51 bulletins hebdomadaires, ajouté 30 nouvelles pages à notre index des sujets, publié un article de blog et rédigé (avec l’aide de deux invités de renom) une série de 21 articles sur la préparation pour taproot. Au total, Optech a publié plus de 80 000 mots sur la recherche et le développement du logiciel Bitcoin cette année, soit l’équivalent approximatif d’un livre de 250 pages.

Septembre

Les développeurs de Bitcoin ont longtemps discuté de la possibilité d’envoyer des bitcoins à un script qui pourrait limiter les autres scripts susceptibles de recevoir ultérieurement ces bitcoins, un mécanisme appelé conditions de dépense. Par exemple, Alice reçoit des bitcoins dans un script qui peut être dépensé par son portefeuille chaud—mais seulement en les envoyant à un second script qui retarde toute dépense ultérieure par son portefeuille chaud. Pendant ce délai, son portefeuille froid peut réclamer les fonds. S’il ne le fait pas, et que le délai est passé, le portefeuille chaud d’Alice peut dépenser les fonds librement. En septembre, un nouvel opcode OP_TAPLEAF_UPDATE_VERIFY a été proposé pour créer ce genre de conditions de dépense d’une manière qui tire un avantage particulier de la capacité de taproot à dépenser des fonds en utilisant soit juste une signature (dépense par keypath) ou un arbre de scripts MAST-like (dépense par scriptpath). Le nouvel opcode serait particulièrement utile pour créer des joinpools qui pourraient augmenter considérablement la confidentialité en permettant à plusieurs utilisateurs de partager facilement et en toute confiance la propriété d’un UTXO.

Octobre

En octobre, les développeurs de Bitcoin ont discuté d’une nouvelle façon pour une transaction d’identifier quel ensemble de bitcoins elle voulait dépenser. Actuellement, les bitcoins sont identifiés par leur emplacement dans la transaction qui les a dépensés en dernier ; par exemple “transaction foo, sortie zéro”. Une nouvelle proposition permettrait d’identifier les bitcoins à l’aide d’une transaction précédente qui les a dépensés ainsi que de leur position dans la hiérarchie descendante et de leur emplacement ; par exemple, “transaction bar’s second enfant, sorite zero”. Il a été suggéré que cela offrirait des avantages pour des conceptions telles que eltoo, usines à canaux, et watchtowers, qui sont toutes utiles aux protocoles de contrat tels que LN.

En octobre également, une combinaison d’idées existantes pour améliorer LN a été regroupée dans une proposition unique qui apporterait certains des avantages d’eltoo, mais sans nécessiter l’embranchement convergent SIGHASH_ANYPREVOUT ou tout autre changement de consensus. La proposition réduirait la latence des paiements à une vitesse proche de celle à laquelle les données peuvent voyager dans un sens entre tous les nœuds de routage sur un chemin particulier. Elle augmenterait également la résilience en permettant à un nœud de sauvegarder toutes les informations dont il a besoin au moment de la création d’un canal et d’obtenir toute autre information dans la plupart des cas lors d’une restauration des données. Elle permettrait également de recevoir des paiements avec une clé hors ligne, ce qui permettrait aux nœuds marchands en particulier de limiter la durée d’utilisation de leurs clés par les ordinateurs en ligne.

Novembre

Les développeurs de LN ont tenu le premier sommet général de LN depuis 2018 et ont discuté de sujets tels que l’utilisation de taproot dans LN, notamment les PTLCs, MuSig2 pour les multisignatures, et eltoo ; le déplacement de la discussion sur les spécifications de l’IRC vers les chats vidéo ; de modifications du modèle de spécification BOLTs actuel ; des messages en oignon et offres ; paiements sans blocage ; attaques par brouillage de canal et diverses atténuations ; et du routage par trampoline.

Decembre

Pour les transactions onchain à signature unique, l’augmentation des frais d’une transaction pour encourager les mineurs à la confirmer plus tôt est une opération relativement simple. Mais pour les protocoles de contrat tels que LN et les coffres-forts, tous les signataires qui ont autorisé une dépense ne sont pas forcément disponibles lorsque la hausse des frais est nécessaire. Pire encore, les protocoles contractuels exigent souvent que certaines transactions soient confirmées avant une date limite, sans quoi un utilisateur honnête pourrait perdre de l’argent. Le mois de décembre a vu la publication d’une recherche liée au choix de mécanismes efficaces de répercussion des frais pour les protocoles de contrat, ce qui a contribué à stimuler la discussion sur les solutions à cet important problème à long terme.

Conclusion

Nous avons tenté quelque chose de nouveau dans le résumé de cette année : décrire deux douzaines de développements notables en 2021 sans mentionner le nom d’un seul contributeur. Nous sommes redevables à tous ces contributeurs et souhaitons vivement qu’ils soient crédités pour leur incroyable travail, mais nous voulons également reconnaître tous les contributeurs que nous ne mentionnions pas normalement.

Ce sont les personnes qui passent des heures à réviser le code, qui écrivent des tests pour un comportement établi afin de s’assurer qu’il ne change pas de manière inattendue, qui s’efforcent de déboguer de mystérieux problèmes pour les résoudre avant que l’argent ne soit mis en danger, ou qui travaillent sur une centaine d’autres tâches qui ne feraient la une que si elles n’étaient pas effectuées.

Ce dernier bulletin de 2021 leur est dédié. Nous ne disposons pas d’un moyen facile de dresser une liste des noms de ces contributeurs méconnus. Au lieu de cela, nous avons omis tous les noms de ce bulletin pour souligner que le développement de Bitcoin est un travail d’équipe où certains des travaux les plus importants sont effectués par des personnes dont les noms n’ont jamais paru dans aucun numéro de ce bulletin. Nous sommes impatients de voir quels nouveaux développements passionnants ils apporteront en 2022.

Le bulletin Optech reprendra son rythme de publication habituel dès mercredi le 5 janvier.