SIGHASH_ANYPREVOUT

Définition

SIGHASH_ANYPREVOUT (APO, parfois noté NOINPUT dans les premiers drafts) est un nouveau type de signature proposé pour Bitcoin via BIP-118. Il modifie la sémantique des signatures Schnorr de Taproot en omettant l'engagement sur l'input spécifique dépensé : la signature reste valide quel que soit l'UTXO précis qui sera utilisé en input, tant que le scriptPubKey correspond.

Le problème qu'il adresse

Les signatures actuelles (SIGHASH_ALL, etc.) engagent l'input par son outpoint (txid + index). Cela rend la signature dépendante d'une transaction précédente précise. Or, pour certains protocoles, on veut signer une transaction qui pourra s'appliquer à n'importe quel "même type" d'UTXO :

• Eltoo Lightning : un mécanisme de mise à jour de canal sans punition, où chaque état peut remplacer le précédent.
• Statechains : transferts d'UTXO entiers où la signature pré-existante doit s'appliquer à la transaction future.
• Lightning replacement : modifier dynamiquement la transaction d'engagement sans renégocier toutes les signatures.

Origines et débats

L'idée date de 2017-2018 sous le nom SIGHASH_NOINPUT. Christian Decker (Blockstream) et l'équipe Eltoo l'ont poussée comme prérequis pour leur protocole. Le draft initial a été renommé SIGHASH_ANYPREVOUT pour éviter une connotation négative ("no input" suggérait à tort une signature détachable).

Le BIP-118 (Anthony Towns, 2021-2024) propose deux variantes :

| Variante | Engagement | |----------|------------| | SIGHASH_ANYPREVOUT | Ne s'engage pas sur l'outpoint ni sur le scriptPubKey précis | | SIGHASH_ANYPREVOUTANYSCRIPT | Ne s'engage ni sur l'outpoint, ni sur le script, ni sur le montant |

Pourquoi c'est puissant

Avec APO, on peut construire des transactions "génériques" qui s'appliquent à n'importe quel UTXO satisfaisant certaines conditions. Cela débloque :

• Eltoo : canaux Lightning sans surveillance constante ("watchtower light").
• Vaults : trésoreries avec pré-signature d'opérations de retrait/clawback.
• Symmetric channels : architecture de canaux plus simple à raisonner.
• CoinPools : pooling collaboratif d'UTXO.
• Recursive covenants (limités) : sans introduire de nouveaux opcodes.

État de l'activation

APO n'est pas activé sur Bitcoin mainnet. Le BIP-118 est en discussion active mais fait face à plusieurs débats :

• Risque de réutilisation de signature : si une signature est valide pour plusieurs UTXO, un mauvais usage peut perdre des fonds.
• Complexité d'implémentation : nouvel encodage de signature et de tapscript.
• Concurrence avec d'autres propositions : OP_CTV, OP_CAT, LNHANCE bundlent parfois APO.
• Soft fork combiné : peut être activé en même temps que d'autres propositions (LN-Symmetry).

Risques

Le principal risque est le replay de signature : si une signature APO valide est révélée pour un UTXO, elle peut potentiellement signer une transaction sur un autre UTXO de même script. Cela exige une discipline stricte dans la construction des protocoles utilisant APO. C'est notamment pourquoi APO est limité à un sous-type spécifique de Tapleaf et n'affecte pas les transactions standards existantes.

À retenir

SIGHASH_ANYPREVOUT est la pièce manquante pour des protocoles Lightning de seconde génération (Eltoo, LN-Symmetry) et pour de nombreux schémas de vaults. Son activation reste l'un des soft forks les plus discutés de 2025-2026, avec un consensus technique fort mais une activation politique encore incertaine.