Analyser BIP119 et la controverse qui l’entoure

11 janvier 2023 La redaction 15 Views

Ceci est un article d’opinion sur BIP119 (OP_CTV). Si vous souhaitez soumettre un contre-argument, veuillez e-mail Bitcoin Magazine.

BIP119, ou Check Template Verify (CTV), a été au centre d’une controverse absurde et ridicule au cours de la semaine dernière. Il y a deux aspects à l’origine de cette controverse, la fonctionnalité CTV elle-même et l’idée lancée de l’activer à court terme en utilisant le mécanisme controversé Speedy Trial qui a réussi à activer Taproot. Ces deux problèmes ont été confondus au point qu’essayer de les démêler et de discuter de l’un ou de l’autre séparément est devenu, pour le dire à la légère, une entreprise incroyablement difficile.

En tant que l’une des personnes impliquées dans la prise en charge d’un client soft fork activé par l’utilisateur (UASF) pour l’activation de Taproot qui était compatible avec le déploiement Speedy Trial (ST), je peux dire sans réserve que je suis tout à fait contre l’utilisation future de ST comme activation mécanisme. Je vois cela comme une erreur horrible et quelque chose qui met socialement la perception d’un mécanisme de veto et d’une influence surpondérée dans le processus de consensus entre les mains des mineurs. Je crois que l’activation des changements consensuels devrait reposer uniquement entre les mains des utilisateurs, pas des développeurs ni des mineurs. Cela dit, la question de savoir comment activer les changements n’est qu’indirectement liée à la proposition de CTV, et une grande partie de la controverse porte spécifiquement sur le BIP lui-même et le concept général de clauses restrictives.

Il y a beaucoup de confusion quant à ce que CTV peut et ne peut pas accomplir. Une grande partie des critiques contre la proposition elle-même qui ne sont pas enracinées dans des problèmes avec l’activation ou le mécanisme d’activation proposé est basée sur l’idée de dégradations de la fongibilité, c’est-à-dire la possibilité pour quelqu’un de vous envoyer des pièces et de restreindre où vous pouvez les dépenser . Ce n’est pas possible pour deux raisons. Premièrement, CTV limite les pièces en définissant EXACTEMENT où elles doivent aller et les montants exacts. Pour faire quelque chose comme « créer des listes blanches » pour limiter où vos pièces sont dépensables, vous devriez précalculer chaque adresse possible à laquelle quelqu’un serait autorisé à dépenser des pièces, mais aussi pour chacune de ces adresses, calculer chaque montant possible qui pourrait être concevable dépensé jusqu’à la granularité d’un satoshi. Deuxièmement, le destinataire est celui qui fournit une adresse à l’expéditeur, et celui qui décide quel script Bitcoin exact il faut satisfaire pour dépenser les pièces reçues. Si un expéditeur modifie ce script de quelque manière que ce soit, il modifie «l’adresse» et le portefeuille du destinataire ne reconnaîtra même pas les fonds comme étant reçus. Ce n’est pas différent de donner une adresse à quelqu’un et de lui faire envoyer de l’argent dans le portefeuille de quelqu’un d’autre.

Transactions présignées et multisignatures

Les transactions présignées sont un élément très important de la construction de choses au-dessus de Bitcoin. Lightning est construit sur des transactions présignées, les chaînes d’état sont construites sur des transactions présignées et les contrats de journaux discrets sont construits sur des transactions présignées. Combiné avec des scripts multisig, il est possible de garantir qu’un UTXO existant encombré par le multisig ne peut être dépensé que de certaines manières prédéfinies. C’est tout le noyau de base de ces secondes couches.

Toutes les parties impliquées génèrent une adresse multisig, puis choisissent avec quels UTXO la financer. Avant de signer la transaction de financement, ils élaborent la ou les transactions qui dépensent l’UTXO multisig de la ou des manières prédéfinies, puis ils signent et confirment la transaction de financement. Maintenant, sans que toutes les parties acceptent de changer où et dans quelles conditions les fonds sont dépensés, rien ne peut être changé. La destination et les conditions dans lesquelles les fonds seront acheminés vers la destination sont verrouillées. La principale limitation de cette primitive est que, afin de garantir que ces fonds restent limités dans la manière dont ils peuvent être dépensés, tous ceux qui ont contribué de l’argent ou dépendent de ceux-ci. les limitations de dépenses doivent être un participant au contrat multisig. S’ils ne le sont pas, ils doivent faire confiance aux parties réellement impliquées dans le contrat multisig, ou au moins à un certain seuil d’entre elles (par exemple, dans le cas d’un multisig 3 sur 5, ils doivent faire confiance à au moins trois participants pour être honnête). Sans participer, ils doivent faire confiance aux participants pour qu’ils ne signent honnêtement et/ou qu’ils ne suppriment les clés privées sans en conserver de copies.

Quelles sont les limites des transactions présignées ? Vous devez définir chaque détail de la transaction : ce qu’elle fait, où elle dépense les fonds, les blocages éventuels au niveau de la transaction, etc. Vous ne pouvez jamais annuler la signature d’une transaction, vous ne pouvez pas modifier ce que vous avez déjà signé. C’est pourquoi Lightning a besoin de clés de pénalité, et les gens veulent ANYPREVOUT et aussi, car vous ne pouvez pas annuler ou « reprendre » la transaction signée précédente. Tout ce que vous pouvez faire est d’en signer un nouveau et de lui donner la possibilité de mettre à jour ou d’annuler le précédent si quelqu’un essaie de l’utiliser. Parfois, vous voudrez peut-être le faire, parfois vous voudrez peut-être vous assurer que ce n’est pas possible, mais que la transaction signée précédente est verrouillée et qu’il est toujours possible de l’utiliser tant que quelqu’un la conserve. Vous ne pourrez jamais le reprendre.

CHECKTEMPLATEVERIFY / BIP119

La fonctionnalité principale de CHECKTEMPLATEVERIFY (CTV) est de fournir des garanties plus solides dans la situation où vous voulez vous assurer qu’il n’est pas possible de remplacer la transaction initialement signée. Au lieu de devoir faire confiance aux participants multisig pour se comporter honnêtement ou aux générateurs de clés pour supprimer les clés privées, CTV garantit que dépenser une pièce de la manière prédéfinie est littéralement appliqué par des règles de consensus. Ceci est accompli en incluant le hachage de la transaction prédéfinie que vous souhaitez dépenser pour cet UTXO, et en l’incluant dans le script de verrouillage pour cet UTXO lors de sa création. Lorsque vous allez dépenser cette pièce, l’interpréteur de script s’assure que le hachage de la transaction de dépense correspond à ce qui était dans le script de l’entrée, et si le hachage ne correspond pas, il échoue la transaction comme invalide par consensus.

Cela fournit la même fonctionnalité que les transactions multisig et présignées dans les cas d’utilisation où vous voulez garantir que l’ensemble de transactions initial ne peut pas être remplacé, sauf qu’il supprime complètement l’obligation de faire confiance aux participants du quorum multisig pour agir honnêtement ou à quelqu’un pour supprimer les clés privées après signature des opérations. Il n’ouvre aucune nouvelle porte, il ne permet rien qui ne puisse déjà être fait avec des transactions présignées et multisig ; cela supprime simplement la nécessité de participer directement au script multisig afin de ne pas avoir à compter sur des tiers de confiance pour faire respecter la bonne exécution du contrat.

CTV ne fait rien de plus pour permettre la mise en œuvre forcée des «restrictions de liste blanche» afin que les pièces ne puissent être dépensées qu’aux adresses approuvées que ne le font les transactions présignées. Le nombre de combinaisons différentes de montants, d’adresses de destination et de variables spécifiques qui peuvent différer dans les transactions de dépenses qui doivent être précalculées et signées à l’avance pour faire quelque chose comme ça est absurdement lourd et peu pratique à faire pour chaque utilisateur qui se retire à l’avance. C’est aussi ignorer complètement le fait que chaque sortie de changement de chaque transaction précalculée devrait être encombrée de la même manière avec un nombre presque infini de ces combinaisons, et les sorties de changement du prochain ensemble de transactions, et ainsi de suite, et ainsi de suite, dans ce qui est effectivement l’infini. La seule optimisation offerte par CTV est de ne pas avoir à passer les cycles CPU à signer des choses, ce qui ne change rien au fait que cela est en pratique tout simplement insoluble. Pourquoi gérer toute cette complexité et ce précalcul au lieu de simplement refuser de laisser les utilisateurs se retirer, sauf dans un multisig 2 sur 2 où l’échange détient une clé afin qu’ils puissent refuser d’autoriser les « mauvaises transactions » ? Ou tout simplement ne pas laisser les utilisateurs se retirer du tout ?

Le choix

En fin de compte, le choix de ce qu’il faut activer ou appliquer dépend de ce que chaque utilisateur individuel choisit de faire avec son nœud et du résultat cumulé de cela sur l’ensemble du réseau auquel chacun de ces choix individuels s’ajoute. C’est ainsi que Bitcoin fonctionne, et rien ne changera cela – à moins d’une rupture complète de la pensée indépendante et de la prise de décision parmi les utilisateurs. Cela dit, il serait vraiment dommage, à mon avis, qu’une proposition de mise à niveau soit torpillée et abattue sur la base d’une incompréhension totale de ce qu’elle peut et ne peut pas faire, par opposition à des critiques raisonnées et rationnelles d’éventuels inconvénients, inefficacités ou risques qu’il présente pour le réseau. À mon avis, ce ne serait pas une démonstration d’auto-souveraineté des utilisateurs ou une vérification indépendante des faits affirmés par des personnalités publiques, mais une démonstration de pure stupidité et d’ignorance.

J’espère qu’à l’avenir, cette conversation pourra être correctement séparée en deux questions actuellement confondues – la proposition elle-même et les mécanismes d’activation qui pourraient être utilisés pour la mettre en œuvre – au lieu de la situation actuelle où ces deux choses sont extrêmement confondues et non reconnues pour les questions distinctes qu’ils sont. En fin de compte, il est parfaitement rationnel et raisonnable de ne pas soutenir un changement basé sur les risques d’activation du soft fork lui-même ou en raison de lacunes ou de risques légitimes qu’une proposition individuelle présente au réseau. Cependant, je ne pense pas qu’il soit raisonnable d’exprimer un manque de soutien enraciné dans des affirmations complètement non factuelles au sujet d’une proposition et de ce qu’elle peut réellement faire, alors que dans le processus, diffuser des informations erronées sur la proposition elle-même aux personnes qui tentent actuellement d’en savoir plus sur et comprendre la proposition pour prendre leur propre décision. C’est quelque chose que j’appellerais une attaque contre le processus de consensus.