Cette édition spéciale du bulletin d’information d’Optech résume les développements de Bitcoin pendant toute l’année 2020. C’est la suite de nos résumés de 2018 et 2019.

Comme nous l’avons fait dans nos précédents résumés annuels, nous devons faire précéder ce que vous êtes sur le point de lire par des excuses. Beaucoup plus de personnes ont travaillées à la fois sur le maintien et l’amélioration de la technologie Bitcoin que nous ne pourrions jamais écrire. Leurs recherches fondamentales, la révision du code, les corrections de bogues, la rédaction de tests, le travail administratif et d’autres activités ingrates ne peuvent pas être décrites ici—mais elles ne sont pas ignorées. Si vous avez contribué à Bitcoin en 2020, veuillez accepter nos plus sincères remerciements.

Sommaire

Janvier

Plusieurs développeurs ont commencés à travailler sur une spécification pour l’utilisation de contrats logiques discrets (DLC) entre différents logiciels. Les DLC sont un protocole de contrat dans lequel deux parties ou plus acceptent d’échanger de lq éonnqie en fonction du résultat d’un certain événement déterminé par un oracle (ou plusieurs oracles). Après l’événement, l’oracle publie un engagement sur l’issue de l’événement que la partie gagnante peut utiliser pour réclamer ses fonds. L’oracle n’a pas besoin de connaître les termes du contrat (ni même de savoir qu’il existe un contrat). Le contrat peut être rendu indiscernable de nombreuses autres transactions Bitcoin ou il peut être exécuté dans un canal LN. Cela rend les DLC plus privés et plus efficaces que les autres méthodes de contrat connues basées sur un oracle, et on peut dire qu’ils sont plus sûrs car un oracle qui s’engage sur un faux résultat génère des preuves évidentes de fraude. D’ici la fin de l’année, il y aura quatre implémentations compatibles des DLC, une application pour offrir et accepter des dérivés pairs à pairs basés sur les DLC, et plusieurs utilisateurs rapportent qu’ils ont utilisés les DLC dans des transactions sur le réseau principal.

Février

Cinq ans après la première présentation publique sur LN, plusieurs précédentes décisions du protocole censées être temporaires ont été revues. Le changement le plus immédiat a été la mise à jour en février de la spécification LN qui a permis aux utilisateurs de se soustraire aux limites de valeur maximale des canaux et des paiements promulguées en 2016.

Une autre décision prise au début et qui a été reconsidérée était de garder le protocole simple en ouvrant tous les canaux avec un seul financeur. Cela minimise la complexité du protocole mais empêche les bailleurs de fonds des canaux de recevoir des paiements avant d’avoir dépensé une partie de leurs fonds—une position qui crée des obstacles aux commerçants qui rejoignent LN. Une proposition visant à éliminer ce problème est celle des canaux à double financement, où l’ouvreur du canal et sa contrepartie s’engagent à verser une certaine somme d’argent au canal. Lisa Neigut a développé un protocole pour le double financement, mais (comme prévu) c’est complexe. En février, elle a lancé une discussion sur une amélioration progressive de la norme actuelle de financement unique qui permettrait la construction interactive de la transaction de financement. Au lieu du cas actuel où une partie propose l’ouverture d’un canal et l’autre partie l’accepte ou le rejette, les nœuds appartenant aux deux parties pourraient échanger des informations sur leurs préférences et négocier l’ouverture d’un canal qu’elles trouveraient toutes deux souhaitable.

De nouvelles avancées ont également été réalisées sur les plans souvent discutés visant à autoriser le routage par rendez-vous pour le LN, qui a été qualifié de priorité lors de la réunion de spécification LN 2018. Bastien Teinturier a décrit en février une nouvelle méthode permettant d’obtenir une confidentialité équivalente, basée sur une amélioration qu’il avait déjà proposée. Cette nouvelle méthode, appelée chemins aveugles, a ensuite été mise en œuvre en tant que fonctionnalité expérimentale dans C-Lightning.

Mars

Une méthode que les portefeuilles matériels pourraient utiliser pour voler des bitcoins à leurs utilisateurs est la fuite d’informations sur les clés privées du portefeuille via les signatures de transactions qu’il crée. En mars, Stepan Snigirev, Pieter Wuille et plusieurs autres personnes ont discutés des solutions possibles à ce problème pour le système de signature ECDSA actuel de Bitcoin et le système proposé de signature schnorr.

Sommaire 2020
Taproot, tapscript, et signatures schnorr

Presque tous les mois de l’année 2020 ont été marqués par un développement principalement lié à l’embranchement convergent de la proposition taproot (BIP341) qui ajoute également la prise en charge des signatures schnorr (BIP340) et tapscript (BIP342). Ensemble, ces améliorations permettront aux utilisateurs de scripts à une seule signature, de scripts à plusieurs signatures et de contrats complexes d’utiliser des engagements d’apparence identique qui renforcent leur confidentialité et la fongibilité de tous les bitcoins. Les opérateurs bénéficieront de frais moins élevés et de la possibilité de résoudre de nombreux scripts multisignature et contrats complexes avec la même efficacité, des frais peu élevés et un large éventail d’anonymat que les utilisateurs de scripts à signature unique. Taproot et schnorr jettent également les bases de futures mises à jour potentielles qui pourraient améliorer encore l’efficacité, la confidentialité et la fongibilité, telles que l’agrégation de signatures, SIGHASH_ANYPREVOUT, et de changements de langage de script.

Cette section spéciale concentre les synthèses de ces développements en un seul récit qui, nous l’espérons, sera plus facile à suivre que la description de chaque événement séparément dans le mois où il s’est produit.

Le mois de janvier a commencé par une discussion sur les mécanismes d’activation de l’embranchement convergent, Matt Corallo proposant une approche prudente et patiente pour régler les désaccords entre les différents ensembles de parties prenantes. D’autres développeurs se sont concentrés sur la proposition BIP8 afin de pouvoir contourner rapidement le type de problème procédural qui a retardé l’activation de segwit en 2016 et 2017. La discussion sur le mécanisme d’activation précis à utiliser se poursuivra toute l’année, dans un canal IRC dédié et ailleurs, avec à la fois un sondage des développeurs sur la conception du mécanisme et un sondage des mineurs sur leur soutien à taproot.

Le mois de février a vu la première des nombreuses mises à jour apportées au cours de l’année aux algorithmes utilisés pour dériver les clés publiques et les signatures dans la spécification BIP340 des signatures schnorr. La plupart de ces modifications étaient de petites optimisations découvertes à partir de l’expérience de la mise en œuvre et du test de la proposition dans libsecp256k1 et de sa branche expérimentale libsecp256k1-zkp. En février également, Lloyd Fournier a étendu la preuve de sécurité précédente d’Andrew Poelstra pour taproot.

En mars, Bitcoin Core a soigneusement modifié son code de consensus—sans introduire d’embranchement—pour supprimer une inefficacité dans l’analyse de OP_IF et des opcodes de contrôle de flux associés. Actuellement, cette inefficacité ne peut pas être exploitée pour causer des problèmes, mais les capacités étendues proposées pour tapscript auraient permis à un attaquant d’utiliser cette inefficacité pour créer des blocs dont la vérification pourrait nécessiter une grande quantité de calculs.

Bien qu’une grande partie de l’attention publique sur taproot se concentre sur son changement des règles de consensus de Bitcoin, taproot ne sera pas une contribution positive à moins que les développeurs de portefeuilles puissent l’utiliser en toute sécurité. En avril, et tout au long de l’année, plusieurs mises à jour de BIP340 ont modifiées les recommandations sur la manière dont les développeurs doivent générer les clés publiques et le nonce de signature. Ces changements n’intéressent probablement directement que les cryptographes, mais l’histoire du bitcoin comporte de nombreux exemples de personnes ayant perdu de l’argent parce qu’un développeur de portefeuille n’avait pas bien compris le protocole cryptographique qu’il avait mis en œuvre. Espérons que les recommandations de cryptographes expérimentés dans le BIP340 permettront d’éviter certains de ces types de problèmes à l’avenir.

En mai, il y a eu une nouvelle discussion sur l’attaque de la propriété aveugle qui rend dangereux la signature automatique des transactions avec un porte-monnaie matériel. Idéalement, les porte-monnaies matériels pourraient fournir un mode dans lequel ils signeraient automatiquement des transactions garanties pour augmenter le solde du porte-monnaie, comme les créateurs de coinjoins et les jointements LN. Malheureusement, la signature d’une transaction n’est sûre que si vous êtes certain que les entrées sont les vôtres—autrement, un attaquant peut vous faire signer une transaction qui semble ne comporter qu’une seule de vos entrées, puis vous faire signer une autre version de la même transaction qui semble également ne comporter qu’une seule de vos entrées (une entrée différente de la première version), et enfin combiner les signatures des deux entrées différentes dans la transaction réelle qui verse votre argent à l’attaquant. Ce n’est normalement pas un risque parce que la plupart des gens n’utilisent aujourd’hui que des portefeuilles matériels pour signer des transactions où ils possèdent 100% des entrées, mais pour les coinjoins, les jointements LN et d’autres protocoles, il est prévu que d’autres utilisateurs puissent contrôler partiellement ou totalement certaines des entrées. Il a été proposé que taproot fournisse un moyen supplémentaire de s’engager sur les entrées qui peut être utilisé conjointement avec les données fournies dans un PSBT pour garantir qu’un portefeuille matériel ne génère une signature valide que lorsqu’il dispose de suffisamment de données pour identifier toutes ses entrées. Cette proposition a ensuite été acceptée dans le BIP341.

Illustration of using a fake coinjoin to trick a hardware wallet into losing funds

En juillet, une autre discussion a repris à propos d’un problème précédemment connu—le format d’adresse bech32 étant moins efficace que prévu pour empêcher les utilisateurs d’envoyer de l’argent à des adresses non utilisables. Cela n’affecte pas concrètement les utilisateurs actuels de l’adresse bech32, mais cela pourrait être un problème pour les adresses taproot prévues où l’ajout ou la suppression d’un petit nombre de caractères pourrait entraîner la perte de fonds. L’année dernière, il a été proposé de simplement étendre la protection dont bénéficient actuellement les adresses segwit v0 aux adresses segwit v1 (taproot), mais cela réduirait la flexibilité des mises à jour futures. Cette année, après plus de recherche et de débat, il semble y avoir un accord entre les développeurs sur le fait que taproot et les futures mises à jour de scripts basés sur segwit devraient utiliser un nouveau format d’adresse qui est une légère modification des adresses originales BIP173 bech32. Le nouveau format résoudra le problème et fournira d’autres propriétés intéressantes.

En septembre, le code implémentant la vérification de la signature schnorr et les fonctions de signature unique de BIP340 a été fusionné dans libsecp256k1 et a rapidement fait partie de Bitcoin Core. Cela a permis la fusion ultérieure du code de vérification pour taproot, schnorr et tapscript. Le code consiste en environ 700 lignes de modifications liées au consensus (500 sans les commentaires et les espaces blancs) et 2 100 lignes de tests. Plus de 30 personnes ont directement révisé ce PR et les changements associés, et beaucoup d’autres ont participé au développement et à la révision de la recherche sous-jacente, des BIPs, du code associé dans libsecp256k1, et d’autres parties du système. Les nouvelles règles d’embranchement convergent ne sont actuellement utilisées que dans signet et dans le mode de test privé de Bitcoin Core (“regtest”) ; elles doivent être activées avant de pouvoir être utilisées sur le réseau principal de Bitcoin.

De nombreux contributeurs de taproot ont passé le reste de l’année à se concentrer sur la version 0.21.0 de Bitcoin Core, avec l’intention qu’une version mineure ultérieure, peut-être 0.21.1, contienne un code permettant de commencer à appliquer les règles de taproot lorsqu’un signal d’activation approprié est reçu.

Avril

Le protocole payjoin basé sur la proposition Pay-to-EndPoint de 2018 a reçu une impulsion majeure en avril lorsqu’une version de celui-ci a été ajoutée au système de traitement des paiements auto-hébergés BTCPay. Payjoin offre aux utilisateurs un moyen pratique d’accroître leur confidentialité et celle des autres utilisateurs du réseau en créant des transactions qui remettent en cause l’hypothèse selon laquelle la même personne possède tous les éléments d’une transaction. La version BTCPay de payjoin sera bientôt spécifiée comme BIP78 et son support a été ajouté à d’autres programmes.

Une amélioration largement souhaitée de LN est le passage du mécanisme de sécurité des paiements des contrats à temps de hachage (HTLC) aux contrats à temps de point (PTLC) qui améliorent la confidentialité des dépensiers et des receveurs contre une variété de méthodes de surveillance. Une complication est que la construction idéale d’un PTLC multipartite est difficile à mettre en œuvre avec le schéma de signature ECDSA existant de Bitcoin (bien que cela soit plus facile avec les signatures schnorr). Au début de l’année, Lloyd Fournier a fait circuler un article analysant les adaptateurs de signature en dissociant leurs propriétés fondamentales de verrouillage et d’échange d’informations de leur utilisation de signatures multipartites, décrivant un moyen facile d’utiliser la multiple signature basée sur Bitcoin Script. Lors d’un hackathon en avril, plusieurs développeurs ont produit une mise en œuvre approximative de ce protocole pour une dérivation de la célèbre bibliothèque libsecp256k1. Plus tard, en septembre, Fournier a fait progresser l’aspect pratique des PTLC sans avoir besoin d’attendre les changements apportés à Bitcoin en proposant une manière différente de construire des transactions d’engagement LN. En décembre, il proposait deux nouvelles façons d’améliorer la robustesse des sauvegardes LN, offrant à nouveau des solutions pratiques aux problèmes des utilisateurs grâce à l’utilisation intelligente de la cryptographie.

En avril, Ethan Kosakovsky a posté une proposition à la liste de diffusion Bitcoin-Dev pour utiliser un trousseau de clés déterministe hiérarchique (HD) BIP32 pour créer des graines pour des trousseaux de clés HD enfants qui peuvent être utilisés dans différents contextes. Cela pourrait résoudre le problème que de nombreux portefeuilles ne permettent pas d’importer des clés privées étendues (xprvs)—ils ne permettent d’importer qu’une graine HD ou des données précurseurs qui sont transformées en graine (par exemple des mots de graine BIP39 ou SLIP39). La proposition permet à un utilisateur possédant plusieurs portefeuilles de les sauvegarder tout en utilisant uniquement la graine du super-keychain. Cette proposition deviendra plus tard BIP85 et sera mise en œuvre dans les versions récentes du porte-monnaie matériel ColdCard.

Deux annonces concernant les coffres-forts ont été faites en avril. Les coffres sont un type de contrat connu sous le nom de condition de dépense qui émet un avertissement lorsque quelqu’un tente de dépenser les fonds du contrat, donnant ainsi au propriétaire du contrat le temps de bloquer une dépense qu’il n’a pas autorisée. Bryan Bishop a annoncé un prototype de coffre-fort basé sur sa proposition de l’année dernière. Kevin Loaec et Antoine Poinsot ont annoncé leur propre projet, Revault, qui se concentre sur l’utilisation du modèle de coffre-fort pour stocker des fonds partagés entre plusieurs utilisateurs avec une sécurité multisig. Jeremy Rubin a également annoncé un nouveau langage de programmation de haut niveau conçu pour la création de contrats intelligents avec l’opcode OP_CHECKTEMPLATEVERIFY, qui pourrait faciliter la création et la gestion des coffres-forts.

Mai

Le projet Bitcoin Core a fusionné plusieurs PR en mai et au cours des mois suivants qui ont amélioré la confidentialité de l’origine de la transaction, à la fois pour les utilisateurs du porte-monnaie Bitcoin Core et pour les utilisateurs d’autres systèmes. Bitcoin Core #18038 a commencé à suivre si au moins un pair avait accepté une transaction générée localement, ce qui a permis au portefeuille de réduire considérablement la fréquence à laquelle Bitcoin Core rediffusait ses propres transactions et a rendu plus difficile pour les nœuds de surveillance d’identifier le nœud à l’origine de la transaction. Les PR #18861 et #19109 ont pu bloquer un type de balayage actif par les nœuds de surveillance en ne répondant qu’aux demandes de transaction des pairs auxquels le nœud a parlé de la transaction, ce qui réduit encore la capacité des tiers à déterminer quel nœud a diffusé une transaction en premier. Les PR #14582 et #19743 permettent au porte-monnaie d’essayer automatiquement d’éliminer les liens de réutilisation d’adresse lorsque cela ne coûte pas de frais supplémentaires à l’utilisateur (ou, alternativement, de permettre à l’utilisateur de spécifier le supplément maximum qu’il est prêt à dépenser pour éliminer de tels liens).

La fin du mois de mai et le début du mois de juin ont vu deux développements importants dans le domaine des échanges de pièces. Coinswap est un protocole sans confiance qui permet à deux utilisateurs ou plus de créer des transactions qui ressemblent à des paiements ordinaires mais qui, en réalité, échangent leurs pièces l’une contre l’autre. Cela améliore la confidentialité non seulement des utilisateurs de coinswaps mais aussi de tous les utilisateurs de bitcoins, car tout ce qui ressemble à un paiement pourrait être un échange de pièces.

  • ● Échanges atomiques succincts (SAS): Ruben Somsen a écrit un article et créé une vidéo décrivant une procédure pour un échange de monnaie sans confiance utilisant seulement deux transactions. Le protocole présente plusieurs avantages par rapport aux conceptions précédentes d’échange de monnaies : il nécessite moins d’espace de bloc, il économise les frais de transaction, il ne requiert que des timelocks renforcés par consensus sur l’une des chaînes dans un échange inter-chaîne, et il ne dépend pas de nouvelles hypothèses de sécurité ou de modifications du consensus Bitcoin. Si taproot est adopté, les échanges peuvent être effectués de manière encore plus privée et efficace.

  • ● Mise en oeuvre de l’échange de monnaie : Chris Belcher a posté une conception pour une implémentation complète d’échange de monnaie. Son post initial comprend l’historique de l’idée de coinswap, suggère des façons dont les conditions multisig nécessaires pour coinswap pourraient être déguisées en types de transaction plus communes, propose d’utiliser un marché pour la liquidité (comme JoinMarket le fait déjà), décrit les techniques de fractionnement et de routage pour réduire les pertes de confidentialité dues à la corrélation des montants ou à l’espionnage des participants, suggère de combiner coinswap avec payjoin, et discute de certaines des exigences de backend pour le système. En outre, il a comparé le coinwap à d’autres techniques de protection de la vie privée telles que l’utilisation de LN, coinjoin, payjoin et payswap. La proposition a fait l’objet d’un nombre important de discussions entre experts et un certain nombre de suggestions ont été intégrées au protocole. En décembre, le logiciel prototype de Belcher créait des échanges de monnaies sur testnet, ce qui a permis de démontrer l’absence totale de possibilité de liaison.

Depuis les premiers jours de Bitcoin, l’un des défis du développement de clients légers avec une sécurité SPV a été de trouver un moyen pour le client de télécharger les transactions affectant son portefeuille sans donner au serveur tiers fournissant les transactions la possibilité de suivre l’historique de réception et de dépense du portefeuille. Une première tentative a consisté à utiliser des filtres bloom de type BIP37 mais la façon dont les portefeuilles les utilisaient n’offrait finalement qu’une confidentialité minimale et créait des risques de déni de service pour les nœuds complets qui les servaient. Un développeur anonyme a posté sur la liste de diffusion Bitcoin-Dev en mai 2016, en suggérant une construction alternative d’un filtre bloom unique par bloc que tous les portefeuilles pourraient utiliser. L’idée a rapidement été affinée, implémentée, et spécifiée, devenant les BIP157 et BIP158 de spécification des filtres de blocs compacts. Cette méthode peut améliorer considérablement la confidentialité des clients légers, bien qu’elle augmente leurs besoins en bande passante, en CPU et en mémoire par rapport aux méthodes courantes actuelles. Pour les nœuds complets, cela réduit le risque de DoS à celui d’une simple attaque par épuisement de la bande passante, que les nœuds peuvent déjà traiter avec des options de limitation de la bande passante. Bien que fusionné côté serveur dans btcd en 2018 et proposé pour Bitcoin Core à peu près au même moment, 2020 a vu la partie P2P du protocole fusionnée par morceaux dans Bitcoin Core en mai jusqu’en août, culminant avec la possibilité pour un opérateur de nœud d’opter pour la création et le service de filtres de blocs compacts en activant seulement deux options de configuration.

Sommaire 2020
Mise à jour majeure des principaux projets d’infrastructure

  • ● LND 0.9.0-beta a publié en janvier une amélioration du mécanisme de liste de contrôle d’accès (“macarons”), a ajouté la prise en charge de la réception de paiements par trajets multiples, a ajouté la possibilité d’envoyer des données supplémentaires dans un message crypté en oignon, et a permis de demander des sorties de fermeture de canal pour payer une adresse spécifiée (par exemple, votre portefeuille matériel).

  • ● LND 0.10.0-beta a publié en mai l’ajout de la prise en charge de l’envoi de paiements par trajets multiples, a permis de financer des canaux à l’aide d’un portefeuille externe via des PSBT, et a commencé à prendre en charge la création de factures plus grandes que 0,043 BTC.

  • ● Eclair 0.4 a publié en mai l’ajout de la compatibilité avec la dernière version de Bitcoin Core et a déprécié l’interface graphique Eclair Node (renvoyant les utilisateurs vers Phoenix ou Eclair Mobile).

  • ● Bitcoin Core 0.20.0 publié en juin a commencé à utiliser par défaut les adresses bech32 pour les utilisateurs RPC, a permis de configurer les autorisations RPC pour différents utilisateurs et applications, et a ajouté un support de base pour générer des PSBT dans l’interface graphique.

  • ● C-Lightning 0.9.0 publié en août a fourni une commande pay mise à jour et un RPC pour envoyer des messages sur LN.

  • ● LND 0.11.0-beta publié en août a permis d’accepter les grandes chaînes.

Juin

Le mois de juin a été particulièrement actif pour la découverte et la discussion des vulnérabilités, bien que de nombreux problèmes aient été découverts plus tôt ou entièrement divulgués plus tard. Les principales vulnérabilités sont les suivantes :

  • ● Attaque de surpaiement sur les transactions segwit à entrées multiples : En juin, Trezor a annoncé que Saleem Rashid avait découvert une faiblesse dans la capacité de segwit à prévenir les attaques de surpaiement des frais. Les attaques de surpaiement des frais sont une faiblesse bien connue du format de transaction original de Bitcoin, où les signatures ne s’engagent pas sur la valeur d’une entrée, ce qui permet à un attaquant de tromper un dispositif de signature dédié (tel qu’un portefeuille matériel) en dépensant plus d’argent que prévu. Segwit a essayé d’éliminer ce problème en faisant en sorte que chaque signature s’engage sur le montant de l’entrée dépensée. Cependant, Rashid a redécouvert un problème précédemment découvert et signalé par Gregory Sanders en 2017, où une transaction spécialement construite avec au moins deux entrées peut contourner cette limitation si l’utilisateur peut être trompé en signant deux ou plusieurs variations apparemment identiques de la même transaction. Plusieurs développeurs ont estimé qu’il s’agissait d’un problème mineur—si vous pouvez amener un utilisateur à signer deux fois, vous pouvez l’amener à payer deux fois le destinataire, qui perd également son argent. Malgré cela, plusieurs fabricants de porte-monnaie matériels ont publiés un nouveau micrologiciel qui mettait en œuvre la même protection pour les transactions segwit que celle qu’ils avaient utilisée avec succès pour empêcher les paiements excessifs de frais dans les transactions traditionnelles. Dans certains cas, comme pour le portefeuille ColdCard, cette amélioration de la sécurité a été mise en œuvre de manière non perturbatrice. Dans d’autres portefeuilles matériels, l’implémentation a rompu le support avec les flux de travail existants, forçant des mises à jour de la spécification BIP174 de PSBT et de logiciels tels qu’Electrum, Bitcoin Core et HWI.

    Fee overpayment attack illustration

  • ● Attaque contre l’atomicité des paiements LN : Alors que les développeurs de LN s’efforçaient de mettre en œuvre le protocole de sorties d’ancrage afin d’éliminer les risques liés à l’augmentation rapide des taux d’intérêt des transactions, l’un des principaux contributeurs à ce protocole - Matt Corallo - a découvert qu’il permettait une nouvelle vulnérabilité. Une contrepartie malveillante pourrait tenter de régler un paiement LN (HTLC) à l’aide d’un faible feerate et d’une technique d’épinglage de transaction qui empêche la confirmation rapide de la transaction ou d’une partie de celle-ci. Le retard de confirmation entraîne l’expiration du délai d’attente du HTLC, ce qui permet à l’attaquant de récupérer les fonds qu’il a versé à la contrepartie honnête. Plusieurs solutions ont été proposées, depuis les modifications du protocole LN jusqu’aux marchés tiers, en passant par les modifications du consensus de l’embranchement convergent, mais aucune solution n’a encore gagné en importance.

  • ● attaques rapides par éclipse de LN : bien que les experts du protocole Bitcoin, depuis Satoshi Nakamoto jusqu’à aujourd’hui, soient conscients qu’un nœud isolé de tout pair honnête peut être trompé en acceptant des bitcoins non dépensés, une catégorie de problèmes parfois appelée attaques par éclipse, Gleb Naumenko et Antoine Riard ont publiés en juin un article montrant que les attaques par éclipse pouvaient voler des nœuds LN en deux heures seulement—bien qu’il faille plus de temps pour voler des nœuds LN connectés à leurs propres nœuds de vérification complète. Les auteurs suggèrent la mise en œuvre de plus de méthodes pour éviter les attaques par éclipse, qui ont connu plusieurs développements positifs dans le projet Bitcoin Core cette année.

  • ● Rançon des frais LN : René Pickhardt a publiquement divulgué une vulnérabilité à la liste de diffusion Lightning-Dev qu’il avait auparavant signalée en privé aux mainteneurs de l’implémentation LN près d’un an auparavant. Une contrepartie de canal malveillante peut initier jusqu’à 483 paiements (HTLC) dans un canal LN, puis fermer le canal, produisant une transaction onchain dont la taille est d’environ 2 % d’un bloc entier et dont les frais de transaction doivent être payés par le nœud honnête. Des mesures d’atténuation simples de cette attaque ont été mises en œuvre dans plusieurs nœuds LN et l’utilisation de sorties d’ancrage devrait également être utile, mais aucune solution complète n’a encore été proposée.

  • ● Préoccupation concernant les incitations au minage des HTLC : deux articles sur les pots-de-vin HTLC hors chaîne ont été discutés fin juin et début juillet. Les HTLC sont des contrats utilisés pour sécuriser les paiements LN, les échanges atomiques inter-chaînes, et plusieurs autres protocoles d’échange sans confiance. Ils fonctionnent en donnant à un utilisateur récepteur une période de temps pendant laquelle il a la capacité exclusive de réclamer un paiement en libérant une chaîne de données secrètes ; après l’expiration du temps, l’utilisateur qui dépense peut reprendre le paiement. Les articles ont examinés le risque que l’utilisateur qui dépense puisse soudoyer les mineurs pour qu’ils libèrent les données secrètes mais ne confirment pas la transaction qui les contient, permettant ainsi à la période de blocage d’expirer de sorte que le dépensier récupère son argent tout en apprenant le secret. Le développeur ZmnSCPxj a rappelé aux chercheurs un mécanisme bien connu qui devrait empêcher de tels problèmes, un mécanisme qu’il a aidé à implémenter dans C-Lightning. Bien que l’idée fonctionne en théorie, son utilisation coûtera de l’argent aux utilisateurs. La recherche de meilleures solutions est donc encouragée.

  • ● Attaque par déni de service hors mémoire (InvDoS) : une attaque initialement découverte en 2018 qui affectait les nœuds complets Bcoin et Bitcoin Core, qui a été divulguée de manière responsable et corrigée à l’époque, a été réévaluée en juin 2020 et s’est avérée s’appliquer également au nœud complet Btcd. Un attaquant pouvait inonder le nœud d’une victime d’un nombre excessif de nouvelles annonces de transaction (messages inv), chacune contenant presque le nombre maximum autorisé de hachages de transaction. Lorsque trop de ces annonces étaient mises en file d’attente, le nœud de la victime manquait de mémoire et se plantait. Après que Btcd ait corrigé le problème et que les utilisateurs aient eu le temps de se mettre à jour, la vulnérabilité a été divulguée publiquement.

Le mois de juin a également été marqué par de bonnes nouvelles, avec une équipe de chercheurs travaillant sur l’implémentation du coinjoin Wasabi annonçant un protocole nommé WabiSabi qui devrait permettre des coinjoins coordonnés par un serveur sans confiance avec des valeurs de sortie arbitraires. Il est ainsi plus facile d’utiliser des coinjoins coordonnés pour envoyer des paiements, soit entre les participants au coinjoin, soit à des non-participants. Les développeurs de Wasabi ont travaillé à la mise en œuvre du protocole pendant le reste de l’année.

Juillet

Juillet a vu la fusion de la spécification BIP339 pour les annonces de transactions wtxid. Les nœuds ont historiquement annoncés la disponibilité de nouvelles transactions non confirmées pour le relais en utilisant l’identifiant basé sur le hachage (txid) de la transaction, mais lorsque le code segwit proposé a été examiné en 2016, Peter Todd a découvert qu’un nœud malveillant pouvait amener les autres nœuds du réseau à ignorer la transaction d’un utilisateur innocent en invalidant les données du témoin dans la transaction qui ne font pas partie de son txid. Une solution rapide a été mise en œuvre à l’époque, mais elle présentait quelques inconvénients mineurs et les développeurs savaient que la meilleure solution—malgré ses complexités—était d’annoncer les nouvelles transactions en utilisant leur txid de témoin (wtxid). Moins d’un mois après l’ajout du BIP339 au dépôt des BIP, les annonces de wtxid ont été fusionnées dans Bitcoin Core. Bien qu’il s’agisse apparemment d’un problème mineur sans effet évident sur les utilisateurs, les annonces wtxid simplifient le développement des mises à jour espérées, telles que le relai de paquet.

Août

Après plus d’un an de développement, y compris de multiples changements basés sur le feedback, la dernière révision majeure du BIP325 de la spécification de signet a été fusionnée début août. Signet est un protocole qui permet aux développeurs de créer des réseaux de test publics et également le nom du principal signet public. Contrairement au réseau de test public existant de Bitcoin (testnet), les blocs signet doivent être signés par une partie de confiance. Cela permet d’éviter le vandalisme et d’autres problèmes qui se produisent parce que testnet utilise le mécanisme de convergence du consensus basé sur l’économie de Bitcoin (preuve de travail), même si les pièces de testnet n’ont aucune valeur. La possibilité d’activer optionnellement le signet a finalement été ajoutée à Bitcoin Core en septembre.

Près de deux ans après que Matt Corallo ait proposé pour la première fois le mécanisme d’exclusion du CPFP, la spécification LN a été mise à jour pour permettre la création de sorties d’ancrage qui utilisent les exclusions pour la sécurité. Les sorties d’ancrage permettent à une transaction multipartite de faire l’objet d’un prélèvement de frais même si l’une des parties tente d’utiliser une attaque de type épinglage de transaction pour empêcher le prélèvement de frais. La possibilité de faire monter les frais des transactions même dans des conditions adverses permet aux nœuds LN d’accepter des transactions hors chaîne sans s’inquiéter de l’augmentation des frais à l’avenir. Si, plus tard, il devient nécessaire de diffuser cette transaction hors chaîne, le nœud peut choisir un taux de frais approprié au moment de la diffusion. Cela simplifie le protocole LN et améliore plusieurs aspects de sa sécurité.

Sommaire 2020
Bitcoin Optech

Au cours de la troisième année d’existence d’Optech, 10 nouvelles sociétés membres se sont jointes à nous, nous avons organisé un atelier taproot à Londres, publié 51 bulletins d’information hebdomadaires, ajouté 20 nouvelles pages à notre index des sujets, ajouté plusieurs nouveaux portefeuilles et services à notre index de compatibilité, et publié plusieurs articles de blog sur la technologie de mise à l’échelle du bitcoin.

Septembre

Dans un message du forum de 2011, Hal Finney, l’un des premiers contributeurs à Bitcoin, a décrit une méthode utilisée par Gallant, Lambert et Vanstone (GLV) pour réduire le nombre de calculs coûteux nécessaires à la vérification des signatures des transactions Bitcoin. Finney a écrit une implémentation de preuve de concept qui, selon lui, accélère la vérification des signatures d’environ 25 %. Malheureusement, l’algorithme était protégé par le brevet américain 7,110,538 et ni la mise en œuvre de Finney ni une mise en œuvre ultérieure de Pieter Wuille n’ont été distribuées aux utilisateurs. Le 25 septembre, ce brevet a expiré. Dans le mois qui a suivi, le code a été fusionné dans Bitcoin Core. Pour les utilisateurs avec les paramètres par défaut, l’amélioration de la vitesse sera plus apparente pendant la partie finale de la synchronisation d’un nouveau nœud ou lors de la vérification des blocs après qu’un nœud ait été hors ligne pendant un certain temps. Finney est décédé en 2014, mais nous lui sommes reconnaissant pour ses deux décennies de travail visant à rendre la technologie cryptographique largement accessible.

Square a annoncé la formation de la Cryptocurrency Open Patent Alliance (COPA) pour coordonner la mise en commun des brevets liés à la technologie des crypto-monnaies. Les membres permettent à quiconque d’utiliser librement leurs brevets et, en échange, reçoivent la possibilité d’utiliser les brevets du pool pour se défendre contre les agresseurs de brevets. Au moment de la rédaction de cet article, l’alliance comptait 18 membres: ARK.io, Bithyve, Blockchain Commons, Blockstack, Blockstream, Carnes Validadas, Cloudeya Ltd, Coinbase, Foundation Devices, Horizontal Systems, Kraken, Mercury Cash, Protocol Labs, Request Network, SatoshiLabs, Square, Transparent Systems, et VerifyChain.

Octobre

Le mois d’octobre a vu une augmentation significative des discussions entre les développeurs LN concernant la résolution du problème de brouillage décrit pour la première fois en 2015, ainsi que des problèmes connexes. Un nœud LN peut acheminer un paiement vers lui-même à travers un chemin de 20 sauts ou plus. Cela permet à un attaquant disposant de 1 BTC de verrouiller temporairement 20 BTC ou plus appartenant à d’autres utilisateurs. Après plusieurs heures de blocage de la monnaiet d’autres utilisateurs, l’attaquant peut annuler le paiement et recevoir un remboursement complet de ses frais, rendant l’attaque essentiellement gratuite. Un problème connexe est celui d’un attaquant qui envoie 483 petits paiements par le biais d’une série de canaux, où 483 est le nombre maximum de paiements en attente qu’un canal peut contenir. Dans ce cas, un attaquant disposant de deux canaux, chacun avec 483 créneaux, peut brouiller plus de 10 000 créneaux de connexion honnêtes—encore une fois sans payer de frais. Une variété de solutions possibles a été discutée, y compris les forward upfront fees payés par le commanditaire à chaque noeud le long du chemin, les frais initiaux en retour payés par chaque saut de paiement au saut précédent, une combinaison de frais initiaux et en retour, le routage incrémental imbriqué, et les bons de fidélité. Malheureusement, aucune des méthodes discutées n’a été largement acceptée et le problème n’est donc pas résolu.

Illustration of LN liquidity and HTLC jamming attacks

Deux attaques de vol de monnaie contre LND, découvertes et signalées par Antoine Riard en avril, ont été entièrement divulguées en octobre. Dans un cas, LND a pu être amené à accepter des données non valides ; dans l’autre cas, il a pu être amené à divulguer des données secrètes. Grâce à la divulgation responsable de Riard et à la réponse de l’équipe de LND, nous n’avons connaissance d’aucun utilisateur ayant perdu des fonds. La spécification du LN a été mise à jour pour les deux problèmes afin d’aider les nouvelles implémentations à les éviter.

Plus de cinq ans après l’introduction de la proposition initiale de segwit, et trois ans après son activation, il n’existe toujours pas de moyen universel de créer et de vérifier des messages en texte clair signés à l’aide des clés correspondant à une adresse P2WPKH ou P2SH-P2WPKH. Le problème existe également de manière plus générale : il n’existe pas non plus de méthode largement supportée pour gérer les messages pour les adresses P2SH, P2WSH et P2SH-P2WSH, ni de méthode compatible avec les adresses taproot. La proposition de BIP322 pour une fonction de signature de message générique est une tentative de résoudre tous ces problèmes, mais elle n’a pas réussi à gagner beaucoup de terrain. Cette année a vu une demande de commentaires supplémentaire de la part de son champion, une simplification, et (en octobre) un remplacement presque complet de son mécanisme de base. Le nouveau mécanisme rend la signature des messages potentiellement compatible avec un grand nombre de portefeuilles logiciels et matériels existants, ainsi qu’avec le format de données PSBT, en permettant la signature de transactions virtuelles qui ressemblent à des transactions réelles mais qui peuvent être signées en toute sécurité car elles ne sont pas valides selon les règles de consensus de Bitcoin. Espérons que cette amélioration permettra aux signatures de messages générique de commencer à être adoptées.

Jonas Nick, Tim Ruffing et Yannick Seurin ont publié l’article MuSig2 en octobre décrivant une nouvelle variante du schéma de signature MuSig avec un protocole de signature à deux tours et sans besoin d’une preuve à connaissance nulle. De plus, le premier tour (échange de nonce) peut être effectué au moment de la configuration de la clé avec une variante de signature non interactive qui pourrait être particulièrement utile pour le stockage à froid et les protocoles de contrats hors chaîne tels que LN.

En octobre également, Bitcoin Core est devenu le premier projet à fusionner une implémentation du message addr version 2. Le message addr annonce les adresses réseau de pairs potentiels, permettant aux nœuds complets de découvrir de nouveaux pairs sans aucune coordination centralisée. Le message addr original de Bitcoin était conçu pour contenir des adresses IPv6 de 128 bits, ce qui lui permettait également de contenir des adresses IPv4 codées et des adresses Tor onion version 2. Après presque 15 ans de production, le projet Tor a déprécié les services oignon de la version 2 et cessera de les prendre en charge en juillet 2021. Les nouvelles adresses en oignon de la version 3 sont de 256 bits, elles ne sont donc pas utilisables avec les messages addr originaux. La mise à jour BIP155 du message addr fournit plus de capacité pour les adresses Tor et permet également d’utiliser d’autres réseaux d’anonymat qui nécessitent des adresses plus grandes.

Novembre

Comme mentionné dans la section de février, l’un des défis rencontrés dans le réseau LN actuel est que les utilisateurs et les marchands ont besoin de canaux avec une capacité entrante afin de recevoir des fonds sur LN. Une solution entièrement décentralisée à ce problème pourrait être les canaux à double financement décrits précédemment. Cependant, en novembre, Lightning Labs a pris une autre voie et annoncé une nouvelle place de marché Lightning Pool pour l’achat de canaux LN entrants. Certains opérateurs de nœuds existants fournissent déjà des canaux entrants, soit gratuitement, soit en tant que service payant, mais Lightning Pool pourrait être en mesure d’utiliser sa place de marché coordonnée de manière centralisée pour rendre ce service plus standardisé et compétitif. Il est possible que ce service puisse également être mis à niveau pour fonctionner avec des canaux à double financement lorsqu’ils seront disponibles.

Décembre

L’année dernière, Rusty Russell a publié une première ébauche d’une proposition de spécification pour une offre LN, la possibilité pour un nœud de demander une facture à un nœud récepteur sur le réseau LN à routage en oignon. Bien que le BOLT11 existant fournisse un protocole de facturation, il ne permet aucune négociation au niveau du protocole entre les nœuds émetteurs et récepteurs. Les offres permettraient aux nœuds de communiquer des informations supplémentaires et d’automatiser les étapes de paiement qui nécessitent actuellement une intervention manuelle ou des outils supplémentaires. Par exemple, les offres pourraient permettre aux nœuds LN de gérer des paiements ou des dons récurrents en demandant à un nœud expéditeur de demander une nouvelle facture chaque mois à un nœud récepteur. En décembre 2020, la première d’une série de commits par Russell à C-Lightning pour la mise en œuvre des offres a été fusionnée.

Conclusion

L’une des choses que nous aimons dans le résumé des événements de l’année écoulée est que chaque progrès est pleinement réalisé. Le résumé ci-dessus ne contient pas de promesses sur ce que Bitcoin fera à l’avenir—il énumère uniquement les réalisations effectives accomplies au cours des 12 derniers mois. Les contributeurs de Bitcoin ont de quoi être fiers en 2020. Nous sommes impatients de voir ce qu’ils nous réservent en 2021.

Le bulletin Optech reprendra son rythme de publication habituel du mercredi le 6 janvier.