SIGHASH_ANYPREVOUT

Le BIP-118 définit un nouveau type de clé publique pour tapscript, 33 octets commençant par 0x01, plutôt qu'un indicateur ajouté aux clés ordinaires. Attribué en février 2017, il n'a jamais été activé, et il fonctionne uniquement dans les dépenses par chemin de script, jamais dans les dépenses par chemin de clé. Rien dans votre portefeuille ne peut signer de cette manière, donc tout produit promettant des canaux eltoo sur le réseau principal décrit un avenir.

Comment cela fonctionne

Statut : le BIP-118 est un brouillon, attribué le 2017-02-28, exigeant les BIP-340, BIP-341 et BIP-342, et sa propre section Déploiement indique TODO. Rien n'a été remplacé, car rien n'est devenu actif.

Une signature Taproot s'engage sur l'outpoint du bitcoin dépensé, 36 octets de txid et d'index dans le condensé ANYONECANPAY que le BIP-118 modifie, le soudant à un seul bitcoin pour toujours. Retirez l'outpoint du message signé et la signature cesse de nommer un bitcoin et commence à nommer une forme, de sorte que tout UTXO de cette forme peut y être lié plus tard. Le BIP appelle cela la reliaison dynamique.

Deux variantes sont définies, et la différence entre elles tient à ce sur quoi l'engagement subsiste.

• SIGHASH_ANYPREVOUT, valeur de bit 0x40, supprime l'outpoint mais conserve le montant de l'entrée (8 octets), son scriptPubKey (toujours 35 octets ici) et le hachage de tapleaf. La signature correspond alors à tout bitcoin portant la même valeur sous le même script.
• SIGHASH_ANYPREVOUTANYSCRIPT, valeur de bit 0xc0, supprime en plus le montant, le scriptPubKey et le hachage de tapleaf. Elle correspond à tout bitcoin dont cette clé peut satisfaire le script.

L'adhésion se fait à la création de l'adresse, pas au moment de la signature. Ces clés fonctionnent uniquement par une feuille tapscript, donc l'adresse doit porter une telle feuille dans son arbre de merkle, et tant qu'elle n'est pas dépensée, elle est indiscernable de toute autre adresse Taproot. Une constante sépare les deux : key_version vaut 0x01 pour une clé BIP-118 contre 0x00 pour une clé tapscript ordinaire, donc une seule clé privée ne peut pas produire une signature valide selon les deux règles. Six nouveaux octets hash_type deviennent légaux : 0x41, 0x42, 0x43, 0xc1, 0xc2 et 0xc3.

Où le voir

SIGHASH_ANYPREVOUT n'apparaît sur aucune transaction du réseau principal, et le BIP-118 s'attend à ce qu'il ne soit « utilisé que rarement en pratique » même une fois qu'il existera, car les dépenses par chemin de script sont plus lourdes et plus identifiables.

La conception pour laquelle il a été écrit est eltoo, un schéma de mise à jour hors chaîne. Les protocoles hors chaîne doivent répondre à tout ancien état qu'une contrepartie publie, et comme une signature ordinaire s'engage sur la transaction exacte à laquelle elle répond, une nouvelle signature est nécessaire pour chaque état susceptible d'apparaître. Eltoo utilise plutôt le script et nLockTime pour rendre les signatures asymétriques, de sorte qu'une transaction portant une signature plus récente peut dépenser une transaction portant une signature plus ancienne, mais jamais l'inverse, et une signature de mise à jour peut être appliquée par-dessus toute mise à jour antérieure publiée par votre contrepartie.

Le nom enregistre une correction. Joseph Poon a proposé l'idée sous le nom SIGHASH_NOINPUT en février 2016, après que l'article Lightning original l'a soulevée, et le changement de nom indique que l'entrée n'est pas vraiment ignorée : nSequence est toujours signé, et sous SIGHASH_ANYPREVOUT le script et le montant le sont aussi.

La section sécurité du BIP en nomme le prix : le rejeu. Une signature ANYPREVOUT peut être réutilisée contre tout autre UTXO ayant le même script et la même valeur, et une signature ANYPREVOUTANYSCRIPT contre tout UTXO réutilisant cette clé dans l'un de ses scripts, de sorte que la réutilisation de clé passe d'une nuisance pour la confidentialité à un moyen de perdre de l'argent. Ces transactions sont aussi malléables par des inconnus : quiconque peut fournir une entrée correspondante peut modifier le txid sans clé privée.

SIGHASH_ANYPREVOUT vs SIGHASH_ANYONECANPAY

SIGHASH_ANYONECANPAY existe sur le réseau aujourd'hui et supprime toutes les entrées sauf celle signée ; SIGHASH_ANYPREVOUT supprime aussi une partie de celle qui subsiste. Le BIP-118 décrit son condensé comme le condensé ANYONECANPAY avec l'outpoint retiré, une différence d'une ligne aux grandes conséquences. Une signature ANYONECANPAY ne peut pas être rejouée, car l'outpoint qu'elle nomme ne peut être dépensé qu'une fois. Renoncez à cet engagement et la protection contre le rejeu doit venir du protocole construit par-dessus, non de la signature.