Mes inquiétudes concernant les clauses trop généralisées | par Shinobi [SHI256] | Bloc mémoire de résumé

Les covenants à proprement parler au pays Bitcoin ne sont que des scripts ou des fonctionnalités qui vous permettent de restreindre artificiellement l’endroit où un UTXO peut être dépensé. En général, un engagement est défini comme :

« un accord généralement formel, solennel et contraignant : compact. »

Ceux-ci peuvent être très utiles pour toutes sortes de choses, ajoutant une sécurité supplémentaire aux coffres-forts de stockage frigorifique, appliquant le modèle de sécurité des deuxièmes couches, etc. Donc, avant d’entrer dans la question « quels sont les dangers » dans mon esprit, examinons quelques variantes. d’alliances, je l’espère, à venir bientôt. Je n’y vois aucun type de danger mondial, juste une utilité supplémentaire.

Le gain de très haut niveau ici est la possibilité d’inclure un intrant dans une transaction sans référencer un UTXO spécifique par TXID et index de sortie. Lorsque vous incluez une entrée dans une transaction, vous devez pointer vers la transaction exacte qui l’a créée par ID de transaction et par son numéro d’index de sortie dans cette transaction. ANYPREVOUT vous permet de ne pas faire cela. Cela vous permet d’échanger cette entrée avec toute autre entrée pour laquelle la signature correspondrait toujours (donc même script, même montant).

Lightning l’utilise en tirant une astuce intéressante. Vous construisez une transaction (la transaction de déclenchement) qui finance une sortie ANYPREVOUT, puis vous construisez une deuxième transaction (transaction d’engagement) qui la dépense, mais crée simplement à nouveau la même sortie (vous êtes censé payer des frais avec une nouvelle entrée) . L’idée ici est que si la transaction la plus récente est celle qui est poussée vers la chaîne, après une fenêtre de verrouillage, une troisième transaction (transaction de règlement) peut être poussée vers la chaîne pour régler les soldes des canaux. Mais que se passe-t-il si quelqu’un repousse une ancienne transaction d’engagement ? Et bien avec ANYPREVOUT, la transaction d’engagement la plus récente peut dépenser l’ancienne, et en raison de la façon dont les choses sont également structurées, seule une transaction d’engagement plus récente peut dépenser une transaction plus ancienne. Ainsi, une fois l’engagement le plus récent confirmé, tout est garanti pour régler les bons montants sans pénalités.

Il peut également être utilisé pour construire des coffres qui permettent de « récupérer » une transaction pendant une courte durée après avoir été dépensée en utilisant le même type de logique de remplacement mentionné ci-dessus pour les canaux Lightning. Il s’agit d’un mécanisme de sécurité utile pour les configurations de stockage à froid.

Enfin, vous pouvez créer une longue chaîne de transactions prédéfinies qui ne font que recréer encore et encore le même UTXO avec ANYPREVOUT. Ceci est très utile pour s’engager sur d’autres ensembles de données et garantir qu’un seul engagement est effectué (car vous pouvez suivre la chaîne de transaction unique et voir à quoi d’autre les autres sorties s’engagent). Le concept Spacechains de Ruben Somsen utilise ce schéma. Je tiens cependant à noter que cela n’est utile en aucun cas pour l’activité économique générale, car une chaîne de transactions prédéfinie ne faisant rien d’autre que recréer le même UTXO encore et encore est inutile pour cela.

OP_CHECKTEMPLATEVERIFY est une proposition très intéressante. Cela vous permet de conclure une alliance appropriée selon laquelle, au niveau du consensus, l’UTXO verrouillé avec OP_CTV ne peut être dépensé qu’à l’endroit que vous définissez. Exactement l’endroit que vous définissez. Vous pouvez également enchaîner les éléments et créer un UTXO verrouillé avec OP_CTV qui crée davantage d’UTXO verrouillés avec OP_CTV et ainsi de suite. Pour ce faire, il inclut le hachage de la transaction que vous souhaitez utiliser comme seul moyen de dépenser un UTXO dans le script de l’UTXO lui-même.

Cela a de nombreuses utilisations. Garantissant le retrait de milliers de clients en créant un UTXO, il faudra un certain temps pour se déployer sur la chaîne, mais il est verrouillé et ne peut pas être arrêté. Excellente option pour les échanges de garde dans des environnements à frais élevés. Il peut être utilisé pour créer une variante de fabrique de canaux. Chambres fortes sécurisées pour chambres froides. Même les canaux Lightning qui ne nécessitent aucune interaction pour recevoir de l’argent.

Mais encore une fois, je tiens à souligner que cela n’est pas vraiment utile pour encombrer à jamais une pièce destinée à être utilisée dans le commerce général. Vous ne pouvez pas connaître toutes vos transactions à l’avance, vous ne pouvez donc pas verrouiller une pièce destinée à être utilisée librement avec OP_CTV. Vous ne pouvez pas en savoir beaucoup à l’avance, avant de ne pas pouvoir le faire, donc inévitablement les chaînes de transactions verrouillées par OP_CTV doivent prendre fin et créer des UTXO non encombrés par OP_CTV.

Le péril

Aucune des choses ci-dessus ne peut réellement poser de risque systémique pour le système Bitcoin lui-même dans son ensemble. Ils étendent la programmabilité et les fonctionnalités qui peuvent être utilisées pour étendre les protocoles de couche secondaire et améliorer la sécurité. Ils offrent un moyen d’encombrer les pièces plus strictement que les règles mondiales, mais logiquement, un contrôle plus strict doit finalement atteindre un point final. Cependant… les pactes en général pourraient absolument constituer des menaces systémiques mondiales s’ils étaient assez généralisés. Les deux schémas ci-dessus nécessitent de savoir exactement où vous voulez que les pièces aillent jusqu’à la fin de l’alliance, puis elles sont à nouveau gratuites. Et si j’avais une alliance qui n’exigeait pas de le savoir ?

Pensez à Blockstream AMP (Asset Management Platform). Il s’agit d’un outil pour la blockchain Liquid permettant aux émetteurs d’actifs d’émettre leurs actifs dans 2 des 2 portefeuilles multisig où ils possèdent une clé et le propriétaire possède l’autre. Le but est que les émetteurs soient en mesure de se conformer aux exigences réglementaires pour autoriser uniquement certaines personnes à détenir l’actif, pour examiner les transactions à la recherche de problèmes juridiques avant de les approuver, etc. Le problème est cependant qu’il ne s’agit pas d’une règle consensuelle. C’est un processus de couche application. Ces clés peuvent être compromises, ces réglementations peuvent changer, ces actifs ont la possibilité de quitter ce jardin clos sans changer le consensus mondial.

Mais et si vous pouviez faire quelque chose comme ça avec une alliance ? Et si je pouvais structurer un script Bitcoin de manière à ce que le propriétaire présumé puisse le dépenser, mais que le gouvernement puisse également le faire avec sa propre clé ? Et si ce script imposait également qu’il s’agissait d’UTXO ? ne soit envoyé qu’à un script similaire sans avoir à définir à l’avance la clé du propriétaire apparent? Le script ne se soucie pas de la clé du propriétaire, mais simplement du fait que la clé du gouvernement est dans le script et peut également être dépensée.

Ces pièces ne pourraient jamais échapper à ce système, par consensus, sans un hardfork.

Et si le script était verrouillé sur une clé avec une signature prouvant qu’une autorité d’identité lui a associé une identité du monde réel et l’a approuvée. Et si le script bloquait ces pièces pour toujours afin qu’elles ne puissent être envoyées qu’à d’autres clés « d’identité approuvées » ?

Et si les bourses commençaient à déposer des pièces dans de tels scripts ? Et si les institutions le faisaient ? Une fois que ces pièces sont là, la seule issue est le hardfork. Adieu la fongibilité, adieu.

Mineurs

51% d’attaques. Je suis sûr que la plupart des lecteurs se demandent déjà « peu importe, Bitcoin est déjà en panne à ce stade, de quoi parlez-vous ? Les idiots qui ont enfermé leurs pièces dans des alliances stupides comme celle-là se retrouvent livrés à eux-mêmes. Désolé, votre problème.

Eh bien… non, une attaque à 51 % ne signifie pas que Bitcoin est cassé. À moins qu’une coordination mondiale massive ne se produise de concert, une attaque à 51 % est une entreprise très coûteuse qui ne peut finalement faire que deux choses :

• censurer les transactions tant qu’ils peuvent se permettre de poursuivre l’attaque
• réorganiser un bloc pour annuler des transactions

51 % des attaques ne « cassent » pas le Bitcoin à moins qu’elles ne puissent se poursuivre indéfiniment. Ils le perturbent simplement. Mais si vous introduisez les types de clauses générales qui pourraient permettre des scripts restrictifs de manière permanente, vous ne pourrez jamais y échapper comme je l’ai mentionné ci-dessus… eh bien. Et si vous extorquiez les utilisateurs avec votre attaque 51 % pour qu’ils accèdent à ceux-ci ? Ces pièces ne pourraient jamais échapper à ces alliances sans un hardfork. Une attaque à 51 % est désormais un moyen de réaliser une attaque systémique mondiale permanente contre l’offre de pièces. Il ne disparaît pas seulement lorsque l’attaque disparaît, il reste pour toujours à moins que vous ne puissiez accomplir un hard fork (bonne chance).

Je pense que tout ce qui permet des conséquences permanentes plutôt que transitoires en raison d’un 51% est insensé, et c’est quelque chose qui permettrait à de mauvais acteurs de tirer parti d’une telle attaque pour bifurquer de manière permanente l’offre de pièces et compromettre la fongibilité et la confidentialité.

Alors je suppose que ma dernière pensée ? N’oubliez jamais l’ancre de chaîne. (Si vous n’avez pas entendu parler de Chain Anchor, lisez ceci.)