Tous les détails sont cependant très différents.
Une transaction Bitcoin protégée n’est qu’un blob de données avec un préfixe (quelque chose comme « shbtc : ») inclus dans une transaction Bitcoin utilisant OP_RETURN, le champ témoin ou une autre méthode de transport de données. Cela n’a aucune signification pour Bitcoin, le réseau Bitcoin ne fait rien pour le vérifier ni pour appliquer des règles à son encontre. Il est parfaitement possible que des transactions Bitcoin protégées invalides se retrouvent sur la chaîne, et c’est le travail d’un indexeur Bitcoin protégé, qui surveille passivement la blockchain (lire : nœud) d’ignorer ces transactions lorsqu’elles échouent à la validation et de refuser de les appliquer à la mise à jour de l’état des soldes du réseau.
Un indexeur ne supprime pas les notes d’un ensemble de notes non dépensées comme le fait Bitcoin avec les UTXO. Il utilise un ensemble d’annuleurs. Il s’agit d’un moyen pour un utilisateur de publier publiquement une preuve cryptée et d’annuler qu’une note a été dépensée sans révéler quelle note a été dépensée. L’idée est que plutôt que de voir si une note se trouve dans le « jeu de notes non dépensées », vous vérifiez si un annuleur a déjà été utilisé. Les indexeurs construisent un arbre Merkle qui grandit pour toujours et ne peut être ajouté qu’à chaque sortie de note créée, puis à l’ensemble d’annuleurs.
Pour utiliser ce protocole, tout ce dont vous avez besoin est un nœud Bitcoin et un indexeur Bitcoin protégé. Il n’est pas nécessaire d’avoir recours à un fournisseur de services, à un coordinateur ou à un État hors chaîne pour récupérer les fonds. Cela fonctionne comme le Bitcoin en chaîne, tout ce dont vous avez besoin est votre nœud/indexeur et vos clés.
Chaque portefeuille utilisateur dérive une clé secrète principale, à partir de laquelle tous les autres jeux de clés impliqués sont créés.
Pensez-y d’une manière très similaire à un portefeuille HD en Bitcoin. Vous pouvez générer de nombreux ensembles d’adresses avec cette relation. est votre clé privée, le est utilisé pour annuler les sorties de notes, le est utilisé pour déchiffrer et afficher les notes entrantes, le pour afficher vos transactions sortantes et le est utilisé pour générer une adresse de réception.
Lorsqu’un utilisateur souhaite donner une adresse à quelqu’un pour lui envoyer des fonds, il génère une valeur de diversification similaire à une valeur de dérivation, puis multiplie la valeur par sa clé. Cette clé publique résultante est l’adresse de l’utilisateur.
L’expéditeur génère ensuite une valeur aléatoire, le , qui est nécessaire au cryptage de la sortie de la note ainsi qu’à son annulation (nous y reviendrons dans une seconde). Les sorties de transaction ne contiennent que trois éléments cryptés : la valeur de la sortie, la valeur que le destinataire a donnée à l’expéditeur et la valeur de l’expéditeur. L’expéditeur utilise une paire de clés secrètes éphémères et la clé publique du destinataire pour créer un secret partagé. Les deux parties peuvent générer le même secret en multipliant leur clé privée par la clé publique de l’autre. La sortie de la note est chiffrée à l’aide de ce secret partagé, et l’éphémère est inclus non chiffré afin que le destinataire puisse générer le secret partagé.
Du côté des entrées, deux choses sont nécessaires pour avoir une transaction valide : un annuleur public pour les sorties de notes consommées et une preuve de connaissance nulle prouvant que 1) la sortie de notes est incluse dans l’arbre merkle des notes, 2) la transaction est autorisée par la clé appropriée, 3) l’annulateur est correctement dérivé et 4) aucune inflation ne s’est produite.
Si vous remarquez dans l’image ci-dessus, l’annulateur utilise la clé, la valeur ρ dérivée de et la position de la note dans l’arbre Merkle des sorties de notes. La preuve sans connaissance garantit que tout cela est la raison pour laquelle vous pouvez simplement compter les annulateurs pour les répétitions au lieu de supprimer les notes dépensées. Même si vous ne savez jamais à quelle sortie de note correspond un annuleur, les preuves de connaissance nulle dans chaque transaction garantissent que chaque annuleur ajouté à l’ensemble provient d’une sortie de note valide. Tant que vous n’avez pas de répétitions, vous bénéficiez de la même garantie de double dépense.
Voilà, le protocole vous permet essentiellement d’intégrer des transactions métaprotocoles cryptées sur la blockchain Bitcoin, tout en garantissant que rien n’est dépensé en double et que les pièces ne sont pas gonflées à partir de rien.
Il s’agit en fait d’un système très bien conçu en termes de propriétés de confidentialité, comparable à quelque chose comme les pools protégés Zcash. Il y a des considérations en matière de confidentialité à prendre en compte au moment de l’entrée et de la sortie du métaprotocole, et celles-ci doivent être détaillées dans une prochaine version papier. Il n’y a aucun souci de mesure de la confidentialité ou de remixage périodique comme avec les coinjoins.
Donc, la cheville. L’intention est de créer une cheville à l’aide de PIPEs v2, un système de cryptage témoin. Les PIPE vous permettent de chiffrer une clé privée avec un programme/mécanisme qui ne divulguera pas la clé à moins que vous puissiez fournir une preuve ZK qu’une certaine condition a été remplie (c’est-à-dire l’état d’un UTXO, qu’une transaction a été confirmée, etc.). Cela permettrait à un ancrage de fonctionner sans opérateur, fédération ou tiers dépositaire des fonds.
Cela ne nécessite aucun softfork ou changement de protocole pour Bitcoin et se produit entièrement hors chaîne.
Le plan avec Shielded Bitcoin, et la prochaine partie de leur travail, est un mécanisme de rattachement permettant aux utilisateurs de déposer des fonds dans Shielded Bitcoin à l’aide de clés cryptographiques contrôlées par PIPE, qui seraient ensuite « déverrouillées » en générant une preuve ZK de transactions légitimes confirmées en chaîne.
Des travaux sont actuellement en cours sur le document définissant cet aspect du système et devraient être publiés dans un avenir proche.
Ce message [[alloc] init]publie une proposition Bitcoin protégée pour les transactions Bitcoin privées, apparue pour la première fois sur Bitcoin Magazine et écrite par Shinobi.
