Bitcoin : Les améliorations techniques de 2020

by
Ailleurs
My articles My books
Follow on:

Traduction d’un article de Aaron van Wirdum publié dans Bitcoin Magazine le 31 décembre 2020 :

Apparemment imperturbable, malgré la folie de 2020 et les fluctuations sauvages du prix du bitcoin qui ont conduit à de nouveaux sommets en décembre, la communauté technique de Bitcoin poursuit son œuvre. Bitcoin et les nombreux projets qui l’entourent ont été progressivement améliorés tout au long de l’année. Le logiciel a été optimisé, les bugs corrigés et les fuites de confidentialité corrigées. Mais l’essentiel de ce travail, aussi vital soit-il, ne fait pas la Une des journaux.

Une vue d’ensemble des développements réalisés au cours de l’année qui vient de s’achever met pourtant en évidence les nouvelles étapes de la progression technologique de Bitcoin. La communauté croissante des développeurs de Bitcoin a intégré au cours des douze dernier mois un certain nombre de nouvelles fonctionnalités, plusieurs mises à niveau particulièrement importantes et des améliorations notables :

De nouveaux outils de confidentialité avec PayJoin et CoinSwap

Concernant la confidentialité de Bitcoin, les projets PayJoin et CoinSwap ont fait des avancées prometteuses.

PayJoin, également connu sous le nom de Pay to Endpoint (P2EP), est une astuce qui permet au destinataire d’une transaction d’y participer lui-même via un CoinJoin, tout en recevant un paiement réel de quelqu’un d’autre. Un observateur extérieur effectuant une analyse de la blockchain, suppose généralement que tous les fonds envoyés dans une transaction appartiennent à la même personne, avec PayJoin cette heuristique est brisée. Cela profite à la confidentialité de l’expéditeur comme à celle du destinataire et, si suffisamment de personnes utilisent PayJoin, cela pourrait rendre l’heuristique de « propriété commune des entrées«  totalement inutile et améliorer la vie privée de tout le monde, y compris de ceux qui n’effectuent pas de transactions PayJoin.

Payjoin n’est certes pas une nouveauté. Il fut expérimenté en démo sur le jeu de gambling Bustabit et le logiciel de mixage JoinMarket à la fin de 2018. Samourai Wallet avait en outre publié sa propre version en 2019 – plus limitée et avec des compromis de confidentialité légèrement différents. Mais en 2020 PayJoin a intégré plusieurs projets Bitcoin de premier plan : en avril le processeur de paiements BTCPay Server et le portefeuille Wasabi, JoinMarket en septembre, Blue Wallet en octobre et Sparrow Wallet en novembre.

Dans le même temps, le développeur Chris Belcher a entrepris de réaliser une implémentation de CoinSwap, technique de confidentialité proposée pour la première fois en 2013 par Gregory Maxwell. CoinSwap permet, par des Atomic Swaps, d’échanger des bitcoins sans confiance entre les deux parties. Chaque utilisateur se retrouve ainsi avec des fonds qui ne sont pas liés à son propre historique de transactions.

Belcher, l’un des plus grands experts mondiaux de la confidentialité de Bitcoin, a publié en mai un aperçu détaillé de la façon dont le protocole CoinSwap pourrait être mis en œuvre afin d’assurer une confidentialité maximale. Sa proposition rendrait les transactions CoinSwap impossibles à distinguer des autres transactions en utilisant des techniques de fractionnement pour masquer les montants et empêcher leur suivi par des observateurs extérieurs. Quelques mois plus tard, en juin, la Human Rights Foundation a annoncé que sa première subvention dédiée au développement de Bitcoin irait à Belcher pour l’aider à réaliser son projet.

Après avoir travaillé sur sa mise en œuvre pendant la majeure partie de l’année, Belcher a annoncé en décembre « un grand jour pour la confidentialité et la fongibilité du bitcoin » : il avait effectué la toute première transaction CoinSwap sur le testnet de Bitcoin.

Le réseau Lightning est devenu plus robuste

Le Lightning Network, le protocole de seconde couche de Bitcoin permettant des paiements plus rapides, moins chers et plus confidentiels, a continué de s’améliorer à tous les niveaux en 2020. Les implémentations Lightning de LND, Eclair, C-Lightning et, depuis juillet, d’Electrum ont déployé de nouvelles fonctionnalités. Avec le nombre croissant de projets s’appuyant sur le protocole, le développement de Lightning a été plus intense que jamais. Parmi les développements les plus notables on mentionnera les watchtowers qui apportent une solution concrète à l’un des problèmes du Lightning Network et rendent le protocole plus robuste.

L’un des inconvénients de Lightning Network c’est que les utilisateurs doivent garder un œil sur leurs canaux de paiement pour s’assurer que leurs homologues n’essaient pas de tricher en diffusant des états obsolètes et s’approprier des fonds qui ne sont pas les leurs. Les utilisateurs de Lightning peuvent intervenir si leur partenaire tente de tricher, mais cela nécessite une surveillance constante de la blockchain Bitcoin peu pratique pour les utilisateurs occasionnels.

Pour ne pas passer à côté d’une tentative de triche, le protocole Lightning permet d’externaliser la surveillance des canaux à des observateurs impartiaux appelés watchtowers. Introduit par LND fin 2019, la version alpha de Eye of Satoshi, une implémentation des watchtowers, est sortie en février. Peu de temps après, la spécification du protocole proposée pour les watchtowers a été mise à jour, et C-Lightning prend en charge Eye of Satoshi depuis mai. La version 1 de Eye of Satoshi a suivi en juillet .

Parmi les autres développements notables de Lightning en 2020, citons :
– la poursuite du travail sur les sorties d’ancrage pour s’assurer que les utilisateurs peuvent réclamer unilatéralement des fonds à un canal, même lorsque les frais on-chain ont augmenté plus que prévu depuis la dernière mise à jour du canal de paiement,
– les paiements Multipath qui permettent aux utilisateurs de couper leurs paiements Lightning en morceaux,
– l’application de messagerie Juggernaut,
– l’outil de gestion de canaux Faraday,
– la version bêta de Lightning Loop,
– un certain nombre de corrections de bugs et bien d’autres avancées encore.

Après Miniscript, la programmation de Bitcoin est facilitée avec Minsc

Le code intégré dans les transactions Bitcoin, qui spécifie les conditions à remplir pour dépenser les btc lors d’une prochaine transaction, est écrit dans un langage de programmation spécialement conçu pour Bitcoin. Ce langage, appelé Script, est difficile à utiliser. Plus la transaction est complexe, plus il est difficile de comprendre ce qu’elle permet réellement. Une transaction peut involontairement inclure du code qui permet aux fonds d’être dépensées dans des conditions différentes de celles initialement prévues. C’est l’une des raisons pour lesquelles de nombreuses applications Bitcoin, comme les wallets, n’utilisent pas Script à son plein potentiel.

Pendant les dernières années, les chercheurs Andrew Poelstra, Pieter Wuille et Sanket Kanjalkar ont conçu une version « épurée » de Script, appelée Miniscript. Miniscript est une sélection d’outils soigneusement choisis pour permettre pratiquement tout ce qui peut être fait avec Script, mais sans mauvaise surprise. Une ligne de Miniscript est toujours une ligne valide de Script, mais sans le risque d’une erreur humaine et sans résultats inattendus. En novembre de cette année, Dmitry Petukhov, directeur de la recherche et du développement chez Rugged Bytes, a publié une spécification formelle de Miniscript.

Pour rendre la création de transactions Bitcoin encore plus facile, Wuille avait également conçu un langage de programmation propre à Miniscript, qui pouvait compiler (convertir) en Miniscript, et donc en Script. S’appuyant sur le travail de Wuille, le développeur Nadav Ivgi a développé cette année un autre nouveau langage de programmation appelé Minsc. Annoncé pour la première fois en juillet et suivi d’une mise à jour majeure en novembre, Minsc est toujours un travail en cours, mais devrait grandement simplifier la création de transactions Bitcoin. Cela pourrait aider à débloquer une gamme de fonctionnalités prometteuses qui tirent pleinement parti de la polyvalence de Bitcoin, comme les portefeuilles CoinJoin interopérables, des solutions de contrat intelligents, des protocoles de seconde couche et plus encore.

Des « smart contracts » un peu plus « smart » avec les DLC

Chaque fois que des smart contracts dépendent de données externes – donc qui ne proviennent pas de la blockchain, ils s’appuient sur une source externe appelée « oracle ». Si deux utilisateurs veulent parier sur le résultat d’un match sportif, par exemple, l’oracle devra utiliser le résultat du match pour régler le pari en faveur de celui qui a fait le bon pronostic (du moins en cas de litige).

Un pari sportif peut reposer sur une configuration basique : une adresse multisignature (multisig) deux sur trois où les joueurs et l’oracle détiennent une clé. L’oracle est informé des détails du pari. Après le match, les deux joueurs peuvent coopérer pour envoyer les fonds du multisig au vainqueur sans la clé de l’oracle. Mais si le perdant refuse de coopérer, l’oracle peut utiliser sa troisième clé pour envoyer au gagnant les fonds du multisig. Ce système fonctionne, mais présente plusieurs inconvénients majeurs : Premièrement, les deux joueurs doivent faire confiance à l’oracle qui pourrait s’entendre avec l’un des deux adversaire. Deuxièmement, l’oracle doit être informé du pari et peut-être jouer un rôle actif dans le processus de règlement. Cela signifie que les joueurs n’ont aucune confidentialité vis-à-vis de l’oracle. Enfin cette configuration ne fonctionne plus si un grand nombre de joueurs participent au même pari.

En 2017, dans le cadre du MIT Media Lab’s Digital Currency Initiative, le chercheur Thaddeus Dryja a proposé une solution plus adaptée : les Discreet Log Contracts (DLC). Les DLC utilisent une astuce mathématique où l’oracle publie une signature cryptographique qui correspond au résultat d’un événement. Dans l’exemple ci-dessus, l’oracle publiera une signature si la première équipe gagne, et une signature différente si l’autre équipe gagne. L’astuce : le smart contract est conçu pour permettre au joueur gagnant d’utiliser la signature publiée pour réclamer les fonds.

Dans un DLC, l’implication de l’oracle dans le contrat intelligent est réduite à la publication d’une signature ; cela pourrait, dans les paris sportifs par exemple, être effectué par un service d’information existant, à travers des publications régulières. Cela signifie que l’oracle n’a pas besoin d’être informé des détails du pari, et n’a même pas besoin de savoir qu’il y a eu un pari. Cela signifie également que le nombre de personnes qui participent au pari n’a aucune importance. Et bien qu’oracle puisse en théorie encore s’entendre avec quelqu’un et diffuser un mauvais résultat, ce comportement malhonnête apparaitrait publiquement et ternirait la réputation de l’oracle.

En janvier de cette année, Chris Stewart a annoncé que sa société Suredbits, en collaboration avec Crypto Garage, avait commencé à travailler sur une spécification pour les DLC . En février, l’ingénieur de Suredbits Nadav Kohen a poursuivi ce travail. Et en septembre, Suredbits et Crypto Garage avaient développé un logiciel fonctionnel : Stewart et le développeur Nicolas Dorier se sont engagés dans le tout premier DLC de Bitcoin pour parier sur le résultat de l’élection présidentielle américaine. Stewart, qui avait parié sur Biden, a réclamé ses gains en décembre.

Conserver des fonds devient plus sûr avec les Bitcoin Vaults

La longue liste de piratages d’échange et autres vols ​​de bitcoins témoigne du fait que le stockage sécurisé des clés privées continue d’être un défi, en particulier lorsque des fonds importants sont en jeu.

Mais des solutions plus sécurisées pour stocker les pièces sont en cours de développement. Les Bitcoin Vaults – un concept datant de 2016 – sont un type de smart contract qui sécurise les fonds en exigeant plusieurs transactions confirmées et un délai pour pouvoir les dépenser vraiment. Cela donne aux victimes potentielles la possibilité de réagir en cas de vol avant qu’il ne soit trop tard. 2020 a vu la sortie de deux types de prototypes de Vaults :

Le premier prototype a été annoncé par Bryan Bishop, contributeur de Bitcoin Core, en avril. En bref, la conception de Bishop est basée sur une transaction pré-signée (et non diffusée) qui transfère (une partie) des fonds du Vault vers le hot wallet d’un utilisateur avec un délai de verrouillage, tandis que une option de dépense alternative sans timelock peut rediriger les pièces vers une autre adresse, peut-être un nouveau Vault encore plus sécurisé. Il est important de noter que la clé privée utilisée pour pré-signer les transactions est supprimée lors de la création du coffre-fort, de sorte qu’un attaquant ne peut jamais voler que la transaction pré-signée elle-même.

La configuration rend le vol des fonds extrêmement difficile. Si la transaction pré-signée est volée, le voleur peut simplement dépenser les fonds du « hot wallet », et si la victime ne fait pas confiance à la sécurité de ce wallet, elle peut utiliser le timelock pour déplacer les pièces vers l’autre adresse plus sécurisée. (Pour empêcher le voleur de voler les pièces en compromettant simplement le hot wallet et en attendant patiemment que l’utilisateur du coffre-fort y envoie ses fonds, la conception de Bishop ne permet utilisateurs de retirer du Vault que par petits morceaux.)

Un peu plus tard en avril, le développeur Antoine Poinsot, a annoncé une version alternative de Vault, appelée Revault, qu’il a conçue avec le CEO de Chainsmiths, Kevin Loaec. Revault ressemble au Vault de Bishop à certains égards, notamment son utilisation de transactions pré-signées, mais il est spécialement conçu pour les configurations multi-utilisateurs, utilisant une adresse multisig. Revault permet à un sous-ensemble prédéterminé d’un groupe d’utilisateurs de dépenser des pièces du coffre-fort vers un portefeuille actif, également avec un délai. Cependant, tout participant peut utiliser ce délai pour renvoyer les fonds au Vault s’il n’est pas d’accord avec la dépense, ou il peut rediriger les fonds vers une autre adresse sécurisée s’il n’a pas confiance.

En outre, Revault exige que lors du retrait du coffre-fort, lorsque le time-lock entre en jeu, les utilisateurs créent immédiatement une transaction à partir du portefeuille actif, ce qui nécessite également la co-signature d’un serveur. Le serveur est programmé pour signer n’importe quelle transaction, mais jamais une transaction conflictuelle, donc si un attaquant compromet à la fois le Vault et le portefeuille actif, il doit réussir à réclamer les fonds avant quiconque et avant l’expiration du délai. Cela devrait indiquer clairement que le portefeuille actif est compromis, alarmant le groupe d’utilisateurs du Revault et leur permettant de rediriger les fonds avant l’expiration du délai.

Taproot est maintenant prêt et son activation est à l’étude

Taproot devrait être la première mise à niveau du protocole Bitcoin depuis l’activation de Segregated Witness en août 2017. Proposé pour la première fois en janvier 2018 par Gregory Maxwell, contributeur de Bitcoin Core, Taproot permet aux utilisateurs de dissimuler des smart contracts dans des transactions Bitcoin régulières : une construction multisig complexe pourrait ainsi être indiscernable d’un simple paiement.

La mise à niveau Taproot inclura également l’algorithme de signature Schnorr. De nombreux cryptographes considèrent que le schéma de signature Schnorr est le meilleur dans le domaine, car ses propriétés mathématiques offrent un niveau élevé d’exactitude, il ne souffre pas de malléabilité et est relativement rapide à vérifier. Les « mathématiques linéaires » de Schnorr permettront également une gamme de nouvelles possibilités, comme des signatures multisig plus compactes, des configurations de smart contracts astucieuses et, bien sûr, Taproot lui-même.

Après un développement continu tout au long de 2020, le code de Taproot a été intégré dans le code de Bitcoin Core en octobre et sera publié dans la version 0.21.0 du logiciel. Cependant, Bitcoin Core 0.21.0 n’intégrera pas le processus d’activation de Taproot. Ce processus sera probablement précisé ultérieurement, dans une version mineure de Bitcoin Core (probablement Bitcoin Core 0.21.1).

La logique d’activation a elle-même fait l’objet de discussions pendant une grande partie de l’année 2020 et plusieurs mécanismes d’activation sont à l’étude. La plupart cherchent à coordonner la puissance de hachage, pour finalement atteindre une date limite si le minimum de soutien n’est pas atteint. Mais comme l’a clairement indiqué un sondage d’octobre publié par AJ Towns, contributeur de Bitcoin Core, tous les contributeurs de Bitcoin Core ne sont pas d’accord sur cette date limite.

Quel que soit le mécanisme d’activation finalement choisi, il semble de plus en plus probable que Taproot sera activé en douceur grâce à la coordination de la puissance de hachage. En novembre, la coopérative de minage Poolin a lancé une initiative encourageant d’autres pools à exprimer leur opinion sur l’activation de Taproot. La réponse est à ce jour très favorable, avec un soutien de plus de 90% de la puissance totale de hachage et aucune opposition exprimée.

Pour un aperçu encore plus complet et détaillé des développements technologiques de Bitcoin en 2020, consultez également la dernière newsletter de Bitcoin Optech.

Source : bitcoinmagazine.com