Vous activerez les alliances et vous l’aimerez

Shinobi’s Strawman est une série hebdomadaire dans laquelle notre rédacteur technique Shinobi défie la communauté Bitcoin, dans le but de susciter des conversations autour de débats techniques houleux.

____________________________________________________________________________

Cela fait deux ans que la dernière mise à jour de Bitcoin, Taproot, a été activée et mise en ligne sur le réseau. Depuis lors, il y a eu une prolifération de modifications proposées pour la prochaine mise à niveau du protocole, et elles semblent s’accumuler plus rapidement que les gens ne peuvent suivre.

Ces propositions relèvent pour la plupart d’une seule catégorie de changement : les pactes. L’objectif fondamental d’un pacte est de changer fondamentalement la façon dont le script restreint les dépenses en Bitcoin. Actuellement, un script dans un UTXO ne peut contrôler ou limiter la façon dont cet UTXO existant peut être dépensé, l’objectif de conception d’un engagement est d’étendre cette restriction afin que le script dans l’UTXO actuellement existant puisse restreindre la façon dont les futurs UTXO non encore créés peuvent être dépensé.

J’ai moi-même exprimé des inquiétudes dans le passé quant aux risques liés aux pactes habilitants, mais je suis arrivé à la conclusion (évoquée ici) que ces inquiétudes initiales étaient bien exagérées. Je continue de penser que des clauses qui autorisent trop de restrictions sur les futurs UTXO pourraient avoir des conséquences négatives, mais ces préoccupations sont principalement ancrées dans de potentiels changements d’incitations, et non dans l’abus des clauses elles-mêmes pour censurer les gens.

Mais voici le plus important : nous avons absolument besoin d’une forme d’engagement pour que la direction d’évolution dans laquelle nous nous sommes engagés fonctionne réellement à long terme. Les systèmes comme Lightning sont tous construits autour de transactions pré-signées utilisées pour restreindre les conditions de dépenses des futurs UTXO, mais cela peut être très limitatif.

Changer l’état d’un canal Lightning avec seulement deux personnes est simple et nécessite simplement la signature de quelques transactions. Le changement de solde, tout nouveau HTLC ou contrat, et quelques transactions pour les gérer. Cependant, le nombre de transactions que vous devez signer commence à augmenter à mesure que la chose que vous essayez de faire est compliquée. C’est-à-dire impliquer plus de deux personnes dans un canal. Pensez aux sanctions, à l’heure actuelle, une personne ne fait que pénaliser l’autre, c’est très simple. La partie tricheuse perd tout son argent au profit de la seule partie trompée.

Comment ça marche avec trois personnes dans une chaîne ? Il ne s’agit plus que tout revienne à une seule personne, le La bonne quantité doit aller voir toutes les autres personnes trompées. Et ce montant change à chaque fois que la chaîne est mise à jour. Ainsi, chaque fois que l’état du canal change, vous devez signer (ou créer d’une manière ou d’une autre) des transactions qui pénaliseront chaque ancien état du canal tout en garantissant que l’argent ira aux autres participants correspondant correctement aux soldes de l’état actuel. Et vous devez d’une manière ou d’une autre vous assurer que seule la pénalité la plus récente peut être utilisée, sinon les anciennes pénalités créées avec des états de canal différents ne distribueront pas l’argent correctement après que quelqu’un ait tenté de tricher. Imaginez devoir signer tout cet ensemble croissant de transactions à chaque fois que vous mettez à jour un canal, c’est totalement inévolutif (si vous pouviez même trouver un moyen de le faire fonctionner logiquement en premier lieu). SIGHASH_ANYPREVOUT (APO) permet également de résoudre ce problème via Elto, permettant aux utilisateurs de simplement remplacer les anciens états par l’actuel au lieu de pénaliser les gens.

Des problèmes similaires se produisent lorsque vous envisagez d’essayer de gérer l’application des choses en chaîne. Si vous regroupez 10 personnes sur un seul canal, que se passe-t-il si l’une d’entre elles ne répond pas ? Vous devez tout fermer en chaîne et empêcher tout le monde de continuer à mettre à jour les choses hors chaîne. Des propositions telles que OP_TAPLEAFUPDATEVERIFY (TLUV) et OP_EVICT offriraient un moyen à un seul utilisateur de quitter un canal de manière non coopérative sans le fermer à tout le monde, ou à tout le monde, sauf une personne qui ne répond pas, d’éjecter efficacement ce groupe hors ligne et de garder le canal ouvert pour eux-mêmes.

De longues chaînes de transactions pré-signées peuvent s’engager à l’avance sur des paiements individuels, des canaux ouverts, etc. Cependant, pour être fiable, cette chaîne de transactions doit commencer à partir d’une adresse multisig dont vous êtes le détenteur de la clé, sinon tout ce à quoi vous vous êtes engagé peut être dépensé deux fois et annulé. Cela nécessite une longue phase de mise en place de création du multisig, tout le monde devant être en ligne pour tout signer, puis enfin le financer. OP_CHECKTEMPLATEVERIFY (CTV) permet de le faire en toute confiance sans avoir à participer à une phase de configuration longue et compliquée.

Partout où nous cherchons et trouvons des problèmes ou des points de friction dans le fonctionnement de Lightning et d’autres protocoles hors chaîne, certaines propositions d’engagement de base peuvent résoudre les problèmes avec élégance. Il y en a aussi beaucoup :

• SIGHASH_ANYPREVOUT
• OP_CHECKTEMPLATEVERIFY
• OP_CHECKSIGFROMSTACK
• OP_TAPLEAF_UPDATE_VERIFY
• OP_EVICT
• OP_TXHASH
• OP_CAT
• OP_VAULT et OP_UNVAULT
• TX_HASH+CSFS
• Clé du modèle

Je ne serais pas non plus choqué s’il m’en manquait. Certaines de ces propositions, ou dérivés, ou de nouvelles, auxquelles on n’a pas encore pensé, seront nécessaires pour continuer à faire évoluer Bitcoin. Il n’y a aucun moyen de contourner ce problème, soit nous acceptons les limitations du Bitcoin tel qu’il est actuellement, soit nous l’améliorons pour répondre à ces limitations.

Nous allons donc faire la même chose que le dernier Strawman. Que pensez-vous des alliances ? Avez-vous des propositions spécifiques que vous jugez les plus intéressantes ou utiles ? Avez-vous une idée de ce qui pourrait être construit ou des problèmes qui pourraient être résolus en les utilisant ? Y a-t-il des choses que vous ne comprenez pas à leur sujet ? Comment fonctionnent-ils, à quoi servent-ils, quels sont les risques et les inconvénients ? Écoutons ça.

Les DM sont ouverts et opinion@bitcoinmagazine.com est disponible si cela fonctionne mieux comme méthode de soumission. Mercredi prochain, nous ferons la même chose que la dernière fois et je passerai en revue et publierai les réponses avec les réponses à toutes les questions ou réflexions sur les réponses.