Cette édition spéciale de la lettre d’information Optech résume les faits marquants de l’évolution du bitcoin pendant toute l’année 2022. C’est la suite de nos résumés des années précédentes 2018, 2019, 2020, and 2021.

Contenus

Janvier

En janvier, LDK a fusionné une implémentation de factures apatrides, qui lui permet de générer un nombre infini de factures sans stocker aucune donnée à leur sujet, sauf si le paiement est réussi. Les factures sans état ont déjà été proposées en septembre 2021 et la mise en œuvre de LDK diffère de la méthode suggérée, bien qu’elle accomplisse le même objectif et ne nécessite aucun changement du protocole LN. Plus tard dans le mois, une mise à jour de la spécification LN a été fusionnée pour permettre d’autres types de factures sans état, avec un support au moins partiel ajouté à Eclair, Core Lightning et LND.

En janvier également, un fond de défense juridique Bitcoin a été annoncé par Jack Dorsey, Alex Morcos et Martin White. Il fournit “une entité à but non lucratif qui vise à minimiser les maux de tête juridiques qui découragent les développeurs de logiciels de développer activement Bitcoin et les projets connexes.”

Février

Une discussion en janvier sur la possibilité d’ajouter plus facilement des frais aux transactions présignées a conduit à une nouvelle discussion en février sur l’idée de Jeremy Rubin de parrainage des frais de transaction de 2020. Plusieurs obstacles à sa mise en œuvre ont été mentionnés. Bien que la discussion immédiate n’ait pas beaucoup progressée, une technique permettant d’atteindre des objectifs similaires—mais qui, contrairement au parrainage, ne nécessitait pas de soft fork—a été proposée en octobre.

La prise en charge précoce par LDK des factures apatrides lui a permis d’ajouter une méthode nouvelle et simple pour le chargement équilibrant un nœud LN appelé paiements de nœuds fantômes.

Illustration of phantom node payment path

Mars

L’algorithme de recherche de route publié pour la première fois en 2021 par René Pickhardt et Stefan Richter a reçu une mise à jour en mars, Pickhardt soulignant une amélioration rendant l’algorithme bien plus efficace computationnellement parlant.

Une méthode cohérente pour permettre l’utilisation des canaux zéro-conf a été spécifiée et a commencé à être implémentée, en débutant par l’addition au LDK en mars du champs alias pour les identifiants de canaux (Short Channel Identifier, SCID), suivi par Eclair, Core Lightning et LND.

Illustration of zero-conf channels

Résumé 2022
Replace-By-Fee

Cette année fut aussi le théâtre de nombreuses discussions et d’importantes actions autour de Replace By Fee (RBF). Notre bulletin d’information de janvier résumait une proposition de Jeremy Rubin d’autoriser le remplacement de n’importe quelle transaction par une transaction alternative payant plus de frais dans un court laps de temps après que la transaction originelle ait été prise en compte par un noeud. Passée cette période, les règles existantes s’appliqueraient, n’autorisant le remplacement que pour des transactions qui signalent cette possibilité avec BIP125. Ce fonctionnement permettrait aux marchands d’accepter des transactions non confirmées comme ils le font actuellement, une fois écoulée la période de remplacement. Plus important encore, cela pourrait permettre aux protocoles qui dépendent de la substituabilité des transactions pour leur sécurité de ne pas avoir à se soucier des transactions n’ayant pas optées pour le remplacement (via BIP125) tant qu’un noeud de ce protocole ou une watchtower dispose d’un temps raisonnable pour réagir après avoir eu connaissance d’une transaction.

A la fin du mois de janvier, Gloria Zhao a entamé une nouvelle discussion à propos de RBF en publiant une note sur le contexte entourant la politique RBF actuelle, relevant plusieurs problèmes découverts au cours des dernières années (comme les attaques par épinglage), examinant comment cette politique affecte les interfaces utilisateurs des portefeuilles, et décrivant des améliorations potentielles. Au début du mois de mars, Zhao a poursuivi avec le résumé de deux discussions à propos de RBF entre de nombreux développeurs, l’une en présentiel et l’autre en ligne.

Egalement en mars, Larry Ruane a soulevé plusieurs questions liées à RBF, concernant le remplacement des signatures des transactions (les witnesses) sans pour autant changer les parties d’une transaction dont est dérivé l’identifiant de transaction.

En juin, Antoine Riard a ouvert une pull request (PR) dans Bitcoin Core pour ajouter une option de configuration mempoolfullrbf. Par défaut, cette option répliquerait le comportenement actuel de Bitcoin Core, n’autorisant donc le remplacement que pour les transactions contenant le signal BIP125 approprié. Les noeuds configurés avec cette option définie sur sa valeur alternative accepteraient les transactions de remplacement, même si la transaction remplacée ne signalait pas sa substituabilité, et ce tant au niveau du relai des transactions que dans les blocs. Riard a également débuté un fil sur la liste de diffusion Bitcoin-Dev pour discuter de ce changement. Presque tous les commentaires sur la PR étaient positifs et la plupart des discussions sur la liste de diffusion concernaient d’autres sujets : c’est donc sans surprise que la pull request fut fusionnée environ un mois après son ouverture.

En octobre, Bitcoin Core a commencé la distribution des versions admissibles (release candidates) pour la version 24.0, qui serait la première à inclure l’option de configuration mempoolfullrbf. Dario Sneidermanis, voyant les notes de version préliminaires à propos de la nouvelle option, posta sur la liste de diffusion Bitcoin-Dev que l’activation de l’option par trop d’utilisateurs et de mineurs rendrait fiable le remplacement de transactions ne signalant pas la substituabilité. Une fiabilité accrue du remplacement des transactions ne signalant pas leur substituabilité rendrait également plus fiable le vol de services acceptant les transactions non confirmées comme finales, requérant de ces services un changement de leur fonctionnement. La discussion s’est poursuivie la semaine suivante, et celle encore après. Un mois après que Sneidermanis eut soulevé ses premières inquiétudes sur la liste de diffusion, Suhas Daftuar résumait certains des arguments contre la nouvelle option et ouvrait une PR pour la retirer de Bitcoin Core. D’autres PR similaires ont été ouvertes précedemment ou par la suite, mais celle de Daftuar concentra l’essentiel de la discussion autour du potentiel retrait de l’option.

De nombreux contre-arguments en faveur du maintien de l’option mempoolfullrbf furent formulés sous la PR de Daftuar, comme les témoignages de plusieurs développeurs de portefeuilles indiquant le cas relativement régulier d’utilisateurs souhaitant remmplacer leur transaction bien qu’ils n’aient pas signalé la substituabilité via BIP125.

A la fin du mois de novembre, Daftuar avait fermé sa PR et le projet Bitcoin Core avait publié la version 24.0 du logiciel, avec l’option mempoolfullrbf. En décembre, le développeur 0xB10C publia un site internet pour suivre l’occurence de transactions de remplacement ne contenant pas le signal de BIP125, indiquant que n’importe quelle transaction de ce type ayant été minée l’avait probablement été par un mineur ayant activé l’option mempoolfullrbf (ou une option similaire dans un autre logiciel que Bitcoin Core). A la fin de l’année, full-RBF était toujours activement discuté dans d’autres PR de Bitcoin Core et sur la liste de diffusion.

Avril

En avril, Ruben Somsen a proposé l’idée des paiements silencieux, qui permettraient à quelqu’un de payer un identifiant public (une “adresse”) sans pour autant utiliser cet identifiant on-chain. Cela participerait à réduire la réutilisation d’adresse. Par exemple, Alice pourrait publier un identifiant public sur son site internet, que Bob serait ensuite en mesure de transformer en une adresse Bitcoin unique que seule Alice peut dépenser. Si Carole se rend par la suite sur le site d’Alice et réutilise le même identifiant public, elle dérivera une adresse différente pour payer Alice, que ni Bob ni aucune autre tierce partie ne pourra relier à Alice. Par la suite, le développeur W0ltx a proposé une implémentation des silent payments pour Bitcoin Core, y apportant ultérieurement d’importantes mises à jour.

Lightning Labs a annoncé Taro, une proposition de protocole (basée sur diverses propositions) permettant de créer et transférer des tokens arbitraires sur la chaîne Bitcoin. L’ambition de Taro est d’être utilisé conjointement au Lightning Network pour router des transactions off-chain au travers du réseau. Similairement à des propositions antérieures pour des transferts entre différents actifs au sein du LN, les noeuds intermédiaires qui se contentent de transférer les paiements n’ont pas besoin d’être conscients du protocole Taro ou des détails des différents actifs transférés—ils se contentent de transférer des bitcoins en utilisant le même protocole que n’importe quel autre paiement Lightning.

Avril a aussi été l’occasion d’une discussion autour de l’échange de clés post-quantique, permettant aux utilisateurs de recevoir des bitcoins sécurisés par des clés résistantes aux attaques menées par les ordinateurs quantiques rapides qui pourraient exister dans le futur.

Mai

Le protocole MuSig2 pour la création de multi-signatures schnorr a connu plusieurs développements en 2022. Une proposition de BIP a reçu d’importants retours d’informations en Mai. Plus tard, en octobre, Yannick Seurin, Tim Ruffing, Elliott Jin, and Jonas Nick ont découvert une vulnérabilité affectant certaines façons dont le protocole pourrait être utilisé. Les chercheurs ont annoncé qu’ils prévoyaient de corriger cela à l’occasion d’une mise à jour.

Un projet de BIP pour le relai de paquet a été posté par Gloria Zhao en Mai. Le relai de paquet corrige un problème important avec les variations de frais “fee bumping” CPFP sur Bitcoin Core où les nœuds individuels n’accepteront une transaction enfant de type “fee-bumping” que si sa transaction parent paye un taux supérieur au taux minimum dynamique du mempool du nœud. Cela rend le CPFP insuffisamment fiable pour les protocoles dépendant de transactions présignées, tels que de nombreux protocoles de contrats (y compris le protocole LN actuel). Le relai des paquets permet d’évaluer une transaction parent et enfant comme une seule unité, éliminant le problème—sans pour autant éliminer d’autres problèmes connexes tels que l’épinglage des transactions. Une discussion supplémentaire sur le relai des paquets s’est produit en Juin.

Le mois de mai a également vu la première fusion du projet de bibliothèque du noyau de Bitcoin (libbitcoinkernel), une tentative de séparer autant que possible le code de consensus de Bitcoin Core dans une bibliothèque séparée, même si ce code comporte encore du code non-consensuel. À long terme, l’objectif est de réduire libbitcoinkernel jusqu’à ce qu’elle ne contienne plus que du code de consensus, ce qui permettra à d’autres projets d’utiliser facilement ce code ou aux auditeurs d’analyser les modifications apportées à la logique de consensus de Bitcoin Core. Plusieurs autres PR de libbitcoinkernel seront fusionnés au cours de l’année.

Résumé 2022
Mises à jour majeures des principaux projets d’infrastructure

  • ● Eclair 0.7.0 ajout d’un support pour les sorties d’ancrage, relayer les messages en oignon, et l’utilisation de la base de données PostgreSQL en production.

  • ● BTCPay Server 1.4 ajoute un support pour la variation des frais CPFP, la possibilité d’utiliser des fonctionnalités supplémentaires des URL LN, ainsi que de multiples améliorations de l’interface utilisateur.

  • ● LDK 0.0.105 ajoute la prise en charge des paiements fantômes et d’une meilleure recherche probabiliste des paiements.

  • ● BDK 0.17.0 a facilité la dérivation des adresses, même lorsque le portefeuille est hors ligne.

  • ● Bitcoin Core 23.0 fournit des portefeuilles descripteurs par défaut pour les nouveaux portefeuilles et permet également aux portefeuilles avec descripteurs de prendre facilement en charge la réception vers des adresses bech32m en utilisant taproot. Il a également augmenté sa prise en charge de l’utilisation de ports TCP/IP autres que ceux par défaut et a commencé à autoriser l’utilisation de la superposition de réseau CJDNS.

  • ● Core Lightning 0.11.0 a ajouté la prise en charge de plusieurs canaux actifs vers le même pair et le paiement de factures apatrides.

  • ● Rust Bitcoin 0.28 ajoute la prise en charge de taproot et améliore les API connexes, telles que celles de PSBT.

  • ● BTCPay Server 1.5.1 a ajouté un nouveau tableau de bord sur la page principale, une nouvelle fonction de processeurs de transfert, et la possibilité de permettre l’approbation automatique des paiements à la demande et des remboursements.

  • ● LDK 0.0.108 et 0.0.107 a ajouté la prise en charge de larges canaux et de canaux zéro-conf en plus de fournir un code qui permet aux clients mobiles de synchroniser les informations de routage du réseau (gossip) à partir d’un serveur.

  • ● BDK 0.19.0 a ajouté la prise en charge expérimentale de taproot à travers les descripteurs, les PSBT, et d’autres sous-systèmes. Il a également ajouté un nouvel algorithme de sélection de pièces.

  • ● LND 0.15.0-beta a ajouté la prise en charge des métadonnées de facture qui peuvent être utilisées par d’autres programmes (et potentiellement par les futures versions de LND) pour les factures apatrides et ajoute la prise en charge du portefeuille interne pour recevoir et dépenser des bitcoins vers des sorties de dépense de clés P2TR, ainsi que la prise en charge expérimentale de MuSig2.

  • ● Rust Bitcoin 0.29 a ajouté les structures de données de bloc de relais compact (BIP152) et des améliorations au support de taproot et PSBT.

  • ● Core Lightning 0.12.0 a ajouté un nouveau module bookkeeper, un module commando, et la prise en charge des sauvegardes de canaux statiques, et a explicitement commencé à permettre aux pairs d’ouvrir des canaux zéro-conf avec votre noeud.

  • ● LND 0.15.1-beta a ajouté la prise en charge des canaux zéro-conf, des alias de canaux, et a commencé à utiliser les adresses taproot partout.

  • ● LDK 0.0.111 ajoute la prise en charge de la création, de la réception et de la transmission de messages en oignon.

  • ● Core Lightning 22.11 a commencé à utiliser un nouveau schéma de numérotation des versions et a ajouté un nouveau gestionnaire de modules.

  • ● libsecp256k1 0.2.0 était la première version balisée de cette bibliothèque largement utilisée pour les opérations cryptographiques liées à Bitcoin.

  • ● Bitcoin Core 24.0. 1 a ajouté une option pour configurer la politique Replace-By-Fee (RBF) du noeud, un nouveau RPC sendall pour dépenser facilement tous les fonds d’un portefeuille en une seule transaction, un RPC simulaterawtransaction qui peut être utilisé pour vérifier comment une transaction affectera un portefeuille, et la possibilité de créer des descripteurs à surveiller uniquement, contenant des expressions miniscript pour améliorer la compatibilité avec d’autres logiciels.

Juin

En juin, les développeurs LN se sont rencontrés news204 ln pour discuter de l’avenir du développement des protocoles. Parmi les sujets abordés, citons les canaux LN basés sur taproot, tapscript et MuSig2 (y compris MuSig2 récursif), la mise à jour du protocole de gossip pour annoncer les canaux nouveaux et modifiés, les messages en oignons, les chemins aveugles, le sondage et partage d’équilibre, le routage trampoline, et les protocoles d’offres et LNURL.

Juillet

En juillet, Bastien Teinturier a publié un résumé d’une idée qu’il attribue à Rusty Russell pour limiter le débit des messages en oignon afin d’empêcher les attaques par déni de service. Cependant, Olaoluwa Osuntokun a suggéré de reconsidérer sa proposition de mars pour empêcher l’abus des messages en oignon en faisant payer le relai des données. Il semble que la plupart des développeurs participant à la discussion préfèrent tenter de limiter le débit avant d’ajouter des frais supplémentaires au protocole.

Ce mois-ci, Bitcoin Core a également fusionné un PR en ajoutant la prise en charge de la surveillance uniquement pour les descripteurs de script de sortie écrits en miniscript. Un futur PR devrait permettre au portefeuille de créer des signatures pour les descripteurs de dépenses basés sur miniscript. À mesure que d’autres portefeuilles et dispositifs de signature mettent en œuvre la prise en charge de miniscript, il devrait être plus facile de transférer des politiques entre portefeuilles ou de faire coopérer plusieurs portefeuilles pour dépenser des bitcoins, par exemple des politiques multi-sig ou des politiques impliquant différents signataires pour différentes occasions (par exemple, des signataires de secours)

Août

En août, Eclair a fusionné le support pour le protocole de financement interactif, une dépendance pour le protocole de financement double qui permet à l’un (ou aux deux) des deux noeuds de contribuer aux fonds d’un nouveau canal LN. Plus tard dans le mois, une autre fusion a apporté à Eclair un support expérimental pour le double financement. Un protocole ouvert pour le double financement peut contribuer à garantir que les commerçants ont accès à des canaux qui leur permettent de recevoir immédiatement les paiements des clients.

Antoine Riard et Gleb Naumenko ont publiés un guide sur les attaques par brouillage de canaux et proposé plusieurs ssolutions. Pour chaque canal qu’un attaquant contrôle, il peut rendre plus d’une douzaine d’autres canaux inutilisables en envoyant des paiements qui n’aboutissent jamais—ce qui signifie que l’attaquant n’a pas besoin de payer de coûts directs. Le problème est connu depuis 2015, mais aucune solution proposée précédemment n’a été largement acceptée. En novembre, Clara Shikhelman et Sergei Tikhomirov publiaient leur propre papier avec une analyse et une proposition de solution basée sur de petits frais initiaux et des renvois automatisés basés sur la réputation. Par la suite, Riard a publié une solution alternative impliquant des jetons non négociables spécifiques aux nœuds. En décembre, Joost Jager annonce un utilitaire “simple mais imparfait” qui pourrait aider les nœuds à atténuer certains problèmes de brouillage sans nécessiter de modifications du protocole LN.

Illustration of the two types of channel jamming attacks

Lloyd Fournier a écrit sur les avantages des oracles DLC qui font leurs attestations en utilisant des signatures Boneh-Lynn-Shacham (BLS). Bitcoin ne prend pas en charge les signatures BLS et un soft fork serait nécessaire pour les ajouter, mais Fournier renvoie à un article qu’il a co-écrit et qui décrit comment les informations peuvent être extraites en toute sécurité d’une signature BLS et utilisées avec des adaptateurs de signature compatibles avec Bitcoin sans aucune modification de Bitcoin. Cela permettrait d’avoir des oracles “sans état” où les parties à un contrat (mais pas l’oracle) pourraient se mettre d’accord en privé sur les informations qu’elles veulent que l’oracle atteste, par exemple en spécifiant un programme écrit dans n’importe quel langage de programmation qu’ils savent que l’oracle peut exécuter. Ils pourraient ensuite allouer leurs fonds de dépôt conformément au contrat sans même dire à l’oracle qu’ils prévoyaient de l’utiliser. Au moment de régler le contrat, chacune des parties pouvait exécuter le programme elle-même et, si elles étaient toutes d’accord sur le résultat, régler le contrat en coopération sans faire intervenir l’oracle. Si elles n’étaient pas d’accord, n’importe laquelle d’entre elles pouvait envoyer le programme à l’oracle (peut-être avec un petit paiement pour son service) et recevoir en retour une attestation BLS du code source du programme et de la valeur obtenue en l’exécutant. L’attestation pourrait être transformée en signatures qui permettraient de régler le DLC sur la chaîne. Comme avec les contrats DLC actuels, l’oracle ne saurait pas quelles transactions onchain sont basées sur ses signatures BLS.

Résumé 2022
Bitcoin Optech

Au cours de la cinquième année d’Optech, nous avons publié 51 bulletins hebdomadaires et ajouté 11 nouvelles pages à notre index des sujets. Au total, Optech a publié plus de 70 000 mots sur la recherche et le développement du logiciel Bitcoin cette année, soit l’équivalent approximatif d’un livre de 200 pages.

Septembre

Lisa Neigut a posté sur la liste de diffusion Lightning-Dev une proposition de tarification des frais qui permettrait à un nœud d’annoncer quatre tarifs échelonnés pour les frais de transfert. Une meilleure publicité des frais d’acheminement, y compris la possibilité de fixer des frais négatifs dans certains cas, pourrait contribuer à garantir que les nœuds d’acheminement ont suffisamment de capacité pour relayer les paiements vers leur destination finale. Le développeur ZmnSCPxj, qui avait [posté]news204 lnfees] sa propre solution payante pour améliorer le routage plus tôt dans l’année, a décrit une façon simple d’utiliser les cartes tarifaires : “vous pouvez modéliser une carte tarifaire comme quatre canaux séparés entre les deux mêmes nœuds, avec des coûts différents pour chacun. Si le chemin au coût le plus bas échoue, il suffit d’essayer une autre route qui peut avoir plus de sauts mais un coût effectif plus faible, ou bien essayer le même canal à un coût plus élevé.” Une autre méthode de contrôle des flux de paiement a été suggérée par René Pickhardt.

Octobre

En octobre, Gloria Zhao a proposé d’autoriser les transactions via la version numéro 3 à utiliser un ensemble modifié de politiques de relais de transaction. Ces politiques sont basées sur l’expérience de l’utilisation de CPFP et de RBF, plus des idées pour les relais de paquets, et sont conçues pour aider à prévenir les attaques par épinglage contre les protocoles de contrat à deux parties comme LN—en s’assurant que les utilisateurs peuvent rapidement obtenir des transactions confirmées pour fermer les canaux, régler les paiements (HTLCs), et appliquer les pénalités pour mauvais comportement. Greg Sanders suivra plus tard dans le mois avec une proposition supplémentaire pour les ancres éphémères, une forme simplifiée des sorties ancrées déjà utilisables avec la plupart des implémentations de LN.

Eclair a ajouté le support pour une forme basique de paiements asynchrones lorsque le relai par tremplin est utilisé. Les paiements asynchrones permettent de payer un nœud hors ligne (comme un portefeuille mobile) sans confier les fonds à un tiers. Le mécanisme idéal pour les paiements asynchrones dépend de PTLC, mais une implémentation partielle nécessite simplement qu’un tiers retarde l’envoi des fonds jusqu’à ce que le nœud hors ligne revienne en ligne. Les nœuds Trampoline peuvent fournir ce délai et ce PR les utilise donc pour permettre l’expérimentation des paiements asynchrones.

Le mois d’octobre a également été marqué par le premier de deux bogues d’analyse des blocs qui ont affecté plusieurs applications. Un bogue déclenché accidentellement dans BTCD l’a empêché, ainsi que le programme en aval LND, de traiter les derniers blocs. Cela aurait pu conduire les utilisateurs à perdre des fonds, bien qu’aucun problème de ce type n’ait été signalé. Un deuxième bogue apparenté, cette fois-ci délibérément déclenché, a de nouveau affecté BTCD et LND, ainsi que les utilisateurs de certaines versions de Rust-Bitcoin. Là encore, les utilisateurs risquaient de perdre de l’argent, bien que nous n’ayons pas connaissance d’incidents signalés.

John Light a posté un rapport de recherche qu’il a préparé sur les validity rollups—un type de sidechain où l’état actuel de la sidechain est stocké de manière compacte sur la chaîne principale. Un propriétaire de bitcoins de sidechain peut utiliser l’état stocké sur la chaîne principale pour prouver combien de bitcoins il contrôle dans la sidechain. En soumettant une transaction sur la chaîne principale avec une preuve de validité, il peut retirer les bitcoins qu’il possède sur la chaîne latérale, même si les opérateurs ou les mineurs de la chaîne latérale tentent d’empêcher le retrait. Les recherches de Light décrivent en profondeur les validity rollups, examinent la manière dont leur prise en charge pourrait être ajoutée à Bitcoin et étudient les différents problèmes liés à leur mise en œuvre.

La proposition de BIP324 pour un protocole de transport P2P v2 crypté a été mise à jour et discutée sur la liste de diffusion pour la première fois en trois ans. Le cryptage du transport des transactions non confirmées peut aider à cacher leur origine aux oreilles indiscrètes qui contrôlent de nombreux relais Internet (par exemple, les grands FAI et les gouvernements). Il peut également aider à détecter les falsifications et éventuellement rendre les attaques par éclipse plus difficiles.

Lors d’une réunion des développeurs du protocole Bitcoin, plusieurs sessions ont été transcrites par Bryan Bishop, notamment des discussions sur le cryptage du transport, les frais de transaction et la sécurité économique, le schéma FROST threshold signature, la durabilité de l’utilisation de GitHub pour l’hébergement de discussions sur le code source et le développement, y compris les spécifications prouvables dans les BIP, le relais de paquet et le relai de transaction v3, le protocole minier Stratum version 2, et la fusion du code dans Bitcoin Core et d’autres projets de logiciels libres.

résumé 2022
propositions de Soft fork

Le mois de janvier a commencé avec Jeremy Rubin organisant la première de plusieurs réunions IRC pour examiner et discuter de la proposition de soft fork OP_CHECKTEMPLATEVERIFY (CTV). Pendant ce temps, Peter Todd a posté plusieurs préoccupations concernant la proposition sur la liste de diffusion Bitcoin-Dev, en particulier le fait qu’elle ne semble pas bénéficier à la quasi-totalité des utilisateurs de Bitcoin, comme il pense que les soft forks précédents l’ont fait.

Lloyd Fournier a posté aux listes de diffusion DLC-Dev et Bitcoin-Dev sur la façon dont l’opcode CTV pourrait réduire radicalement le nombre de signatures requises pour créer certains Discreet Log Contracts (DLC), ainsi que le nombre de certaines autres opérations. Jonas Nick a fait remarquer qu’une optimisation similaire est également possible en utilisant le mode de hachage de signature proposé SIGHASH_ANYPREVOUT (APO).

Russell O’Connor a proposé une alternative au CTV et à l’APO—un soft fork ajoutant un opcode OP_TXHASH et un opcode OP_CHECKSIGFROMSTACK (CSFS). L’opcode TXHASH spécifie quelles parties d’une transaction de dépense doivent être sérialisées et hachées, le condensé de hachage étant placé sur la pile d’évaluation pour que les opcodes suivants puissent l’utiliser. L’opcode CSFS spécifierait une clé publique et exigerait une signature correspondante sur des données particulières de la pile—comme le condensé calculé de la transaction créé par TXHASH. Cela permettrait l’émulation de CTV et APO d’une manière qui pourrait être plus simple, plus flexible, et plus facile à étendre par d’autres soft forks ultérieures.

En février, Rusty Russell proposait OP_TX, une version encore plus simple de OP_TXHASH. Pendant ce temps, Jeremy Rubin publiait les paramètres et le code d’un signet avec CTV activé. Cela simplifie l’expérimentation publique de l’opcode proposé et permet de tester beaucoup plus facilement la compatibilité entre les différents logiciels qui utilisent ce code. Toujours en février, le développeur ZmnSCPxj a proposé un nouvel opcode OP_EVICT comme alternative à l’opcode OP_TAPLEAF_UPDATE_VERIFY (TLUV) proposé en 2021. Comme TLUV, EVICT est axé sur les cas d’utilisation où plus de deux utilisateurs partagent la propriété d’un seul UTXO, comme les joinpools, les usines à canaux, et certaines conditions de dépenses. ZmnSCPxj proposera plus tard un nouvel opcode différent, OP_FOLD, comme une construction plus générale à partir de laquelle un comportement de type EVICT pourrait être construit (bien que cela nécessiterait d’autres changements dans le langage Script).

En mars, la discussion sur le CTV et les propositions d’opcode plus récentes ont conduit à une discussion sur la limitation de l’expressivité du langage Script de Bitcoin, principalement pour empêcher les conditions de dépenses récursives—conditions qui devraient être remplies à perpétuité dans chaque transaction dépensant à nouveau ces bitcoins ou tout autre bitcoin fusionné avec lui. Les préoccupations concernaient notamment la perte de résistance à la censure, l’activation de drivechains, l’encouragement de calculs inutiles et la possibilité pour les utilisateurs de perdre accidentellement des pièces en raison de conditions de dépenses récursives.

Le mois de mars a également été marqué par une autre idée de modification du langage Script de Bitcoin, cette fois pour permettre aux futures transactions d’opter pour un langage complètement différent basé sur Lisp. Anthony Towns a proposé l’idée et décrit comment elle pourrait être meilleure que Script et qu’un remplacement proposé précédemment : Simplicity.

En avril, Jeremy Rubin a posté sur la liste de diffusion Bitcoin-Dev son projet de lancer un logiciel qui permettra aux mineurs de commencer à signaler s’ils ont l’intention d’appliquer les règles BIP119 pour l’opcode CTV proposé. Cela a suscité des discussions sur le CTV et des propositions similaires, telles que l’APO. Rubin a ensuite annoncé qu’il ne publierait pas de logiciel compilé pour activer CTV pour le moment, car lui et d’autres partisans de CTV évaluaient les réactions qu’ils avaient reçues.

En mai, Rusty Russell a mis à jour sa proposition OP_TX. La proposition initiale autorisait les conditions de dépenses récursives, ce qui a suscité les préoccupations mentionnées plus haut dans cette section. Au lieu de cela, Russell a proposé une version initiale de TX qui se limitait à permettre le comportement de CTV, qui avait été spécifiquement conçu pour empêcher les conditions récursives. Cette nouvelle version de TX pourrait être mise à jour progressivement à l’avenir pour fournir des fonctionnalités supplémentaires, ce qui la rendrait plus puissante mais permettrait également à ces nouvelles fonctionnalités d’être analysées indépendamment. Une discussion complémentaire en mai a examiné l’opcode OP_CAT (supprimé de Bitcoin en 2010), que certains développeurs suggèrent occasionnellement d’ajouter à l’avenir.

En septembre, Jeremy Rubin a décrit comment une procédure de configuration en confiance pourrait être combinée avec la fonctionnalité APO proposée pour mettre en œuvre un comportement similaire à celui proposé par les drivechains. Empêcher l’implémentation de drivechains sur Bitcoin était l’une des raisons pour lesquelles le développeur ZmnSCPxj a suggéré plus tôt dans l’année que les opérateurs de nœuds complets pourraient vouloir s’opposer aux soft forks qui permettent des conditions de dépense récursives.

En septembre également, Anthony Towns a annoncé une implémentation de Bitcoin conçue spécifiquement pour tester les soft forks sur signet. Basé sur Bitcoin Core, le code de Towns appliquera des règles pour les propositions de soft forks avec des spécifications et des implémentations de haute qualité, ce qui permettra aux utilisateurs d’expérimenter plus facilement les changements proposés—y compris en comparant les changements entre eux ou en voyant comment ils interagissent. Towns prévoit également d’inclure les changements majeurs proposés à la politique de relais des transactions (tels que le relai de paquet).

En novembre, Salvatore Ingala a posté sur la liste de diffusion Bitcoin-Dev une proposition pour un nouveau type de condition de dépense (nécessitant un soft fork) qui permettrait d’utiliser des arbres de merkle pour créer des contrats intelligents qui peuvent transporter l’état d’une transaction onchain à une autre. Cela serait similaires aux contrats intelligents utilisés sur d’autres systèmes de cryptomonnaies, mais serait compatible avec le système existant de Bitcoin basé sur UTXO.

Novembre

Le mois de novembre a vu Joost Jager mettre à jour une proposition de 2019 visant à améliorer le signalement des erreurs dans LN en cas d’échec des paiements. L’erreur signalerait l’identité d’un canal où un paiement n’a pas pu être transmis par un nœud afin que le payeur puisse éviter d’utiliser les canaux impliquant ce nœud pendant un temps limité. Plusieurs implémentations de LN ont mis à jour leur code pour prendre en charge la proposition, même si elles n’ont pas immédiatement commencé à l’utiliser elles-mêmes, notamment Eclair et Core Lightning.

Décembre

En décembre, le développeur de protocole John Law a posté sur la liste d’envoi Lightning-Dev sa troisième proposition majeure de l’année. Comme ses deux précédentes propositions, il a suggéré de nouvelles façons dont les transactions hors chaîne de LN pourraient être conçues pour permettre l’ajout de nouvelles fonctionnalités sans nécessiter de modification au code de consensus de Bitcoin. Dans l’ensemble, Law a proposé des moyens pour les utilisateurs occasionnels de LN de rester hors ligne pendant plusieurs mois, séparer l’exécution de paiements spécifiques de la part du gestionnaire de tous les fonds réglés afin d’améliorer la compatibilité avec les watchtowers, et optimisé les canaux LN pour une utilisation en usines à canaux qui pourrait réduire de manière significative les coûts de l’utilisation du LN sur la chaîne.

Nous remercions tous les contributeurs de Bitcoin cités ci-dessus, ainsi que les nombreuses personnes dont le travail était tout aussi important, pour une autre année incroyable de développement du bitcoin. La lettre d’information d’Optech reprendra son cours normal de publication dès le mercredi 4 janvier.