Fermata #242 - Covenant parte 2: APO

Continua la serie di approfondimenti dedicati ai covenant su Bitcoin. Nella prima puntata ho introdotto il concetto di Bitcoin Script raccontando poi il funzionamento, il contesto storico e le implicazioni di CheckTemplateVerify (CTV): in questa sede la protagonista è Anyprevout (BIP 118).

APO, come viene abbreviata, è una proposta di aggiornamento soft-fork per Bitcoin concepita per introdurre una nuova modalità di firma delle transazioni. In sostanza, Anyprevout permette a una firma digitale di non vincolarsi a uno specifico output precedente, rendendo quella firma riutilizzabile su transazioni diverse purché rispettino determinati criteri. Questa caratteristica apre a miglioramenti al Lightning Network - per esempio con il protocollo eltoo – e consente applicazioni avanzate come i Vault.

Come funziona Anyprevout

Per comprendere Anyprevout, occorre ricordare come funzionano le firme nelle transazioni Bitcoin.

Ogni input di una transazione include una firma digitale che autorizza la spesa di un determinato UTXO (Unspent Transaction Output). La firma viene calcolata generando un hash (sighash) dell’intera transazione: ad esempio, in modalità predefinita SIGHASH_ALL si include anche l’identificatore dell’UTXO, vincolando la firma a quello specifico output. Una firma standard quindi non può essere riutilizzata su una transazione differente: se cambia l’UTXO di origine o altri dettagli, la verifica fallisce.

Con Anyprevout viene introdotto un nuovo modo di firmare le transazioni in Bitcoin. Invece di legare una firma a uno specifico output da spendere – come avviene oggi – si può creare una firma più flessibile, che non fa riferimento a un determinato output passato. È come firmare un documento dicendo: «Questa firma vale per qualsiasi documento con queste caratteristiche, non per uno solo in particolare».

In termini più tecnici, APO aggiunge un nuovo tipo di firma chiamata SIGHASH_ANYPREVOUT. Questo tipo di firma ignora il riferimento preciso all’output speso. La firma può quindi essere riutilizzata su più transazioni diverse, purché rispettino certe condizioni, ad esempio che siano indirizzate alla stessa chiave pubblica.

Esistono due varianti:

• SIGHASH_ANYPREVOUT, che ignora l’identificativo dell’output ma considera lo script e l’importo;

• SIGHASH_ANYPREVOUTANYSCRIPT, che invece ignora tutto: identificativo, script e importo.

Quest’ultima è la più permissiva, perché consente di riutilizzare una firma su qualunque output che sia spendibile con la stessa chiave pubblica, senza badare a come fosse stato originariamente creato.

Anyprevout è opt-in e richiede l’uso esplicito di chiavi speciali. Queste chiavi hanno un marchio particolare – una sorta di prefisso – che segnala ai nodi Bitcoin: «Attenzione, qui si vogliono usare le regole speciali di Anyprevout». Se una transazione non contiene queste chiavi marcate, viene trattata come sempre: nessun comportamento nuovo viene attivato per sbaglio.

Inoltre, ogni firma Anyprevout deve essere accompagnata da una seconda firma normale, chiamata chaperone signature (firma accompagnatrice). È come se, prima di permettere a una firma flessibile e riutilizzabile di avere effetto, il protocollo chiedesse anche una firma tradizionale che confermi: «Sì, questa operazione è davvero autorizzata».

Il contesto storico della proposta

La storia di APO inizia nel 2017, quando Christian Decker, ricercatore di Blockstream e uno dei primi sviluppatori del Lightning Network, presentò una nuova idea tecnica chiamata SIGHASH_NOINPUT. Il suo obiettivo era risolvere un problema fondamentale di Lightning: aggiornare lo stato di un canale senza dover punire chi pubblica uno stato vecchio. Per farlo, serviva un modo per firmare transazioni che non fossero collegate in modo rigido a un determinato punto della blockchain. In altre parole, un modo per dire: «Questa firma è valida, qualunque sia l’output da cui partiamo». Da lì nacque l’intuizione che più tardi avrebbe preso il nome di Anyprevout.

Nel 2019 il developer Anthony Towns riprese l’idea e la perfezionò, integrandola con Taproot, il grande aggiornamento che avrebbe migliorato la privacy e la flessibilità degli script in Bitcoin nel 2021. Towns aggiunse due elementi importanti per renderla più sicura e compatibile con il resto del protocollo:

1. Il prefisso speciale per le chiavi pubbliche coinvolte (così da evitare attivazioni accidentali);

2. La già citata firma accompagnatrice (chaperone signature), per garantire che le firme flessibili potessero essere usate solo nel contesto previsto.

Questa versione aggiornata venne ribattezzata ufficialmente Anyprevout. Offriva le stesse potenzialità della proposta originale di Decker, ma con accorgimenti di sicurezza aggiuntivi e soprattutto si integrava perfettamente con Taproot. In particolare, permetteva anche di chiudere un canale Lightning in modo cooperativo, senza lasciare tracce visibili sulla blockchain (key-path spend), migliorando la privacy delle transazioni.

Nonostante vari proof-of-concept la proposta non ha mai avuto un vero campione a promuoverla attivamente. Dopo il 2019 l'attenzione generale è andata all'attivazione di Taproot (2021) e Anyprevout è rimasta in sospeso. Alcuni, come Matt Corallo, hanno sostenuto di voler aspettare una soluzione più generale che includesse funzionalità tipo noinput per evitare soft fork multipli ravvicinati​. Anche nel 2022, durante il dibattito su CTV, c'è stato chi ha suggerito di attivare APO al suo posto (dato che può replicarne molte capacità), ma senza risultato concreto. In breve, APO è rimasta finora in uno stato di "non priorità", priva di un champion e con consenso insufficiente per procedere all’attivazione.

Gli scenari abilitati da Anyprevout

Lightning Network ed eltoo

Attualmente, ogni volta che due utenti aggiornano lo stato del loro canale Lightning - cioè si scambiano fondi off-chain - devono entrambi conservare con cura l’ultima versione dello stato del canale, perché se uno dei due cercasse di barare pubblicando una vecchia versione sulla blockchain, l’altro avrebbe il diritto di punirlo e prendersi tutti i fondi. È un meccanismo efficace, ma richiede attenzione maniacale ai backup.

Con Anyprevout questo può cambiare, in particolare grazie a eltoo. In questo nuovo schema, non c'è più bisogno di penalizzare nessuno: ogni nuovo aggiornamento del canale può semplicemente sovrascrivere quello precedente, in modo naturale e automatico. Ogni aggiornamento cancella e sostituisce quello precedente. Se qualcuno prova a pubblicare una versione vecchia, la controparte può rispondere pubblicando l’ultima, che automaticamente prende il suo posto e prevale.

Questo modello semplifica di molto la gestione dei canali Lightning:

• Niente più rami complicati di transazioni da custodire;

• Meno rischi in caso di crash o perdita dei dati;

• Maggiore sicurezza per chi non è sempre online o non può permettersi software sofisticati per monitorare la rete.

Vault, DLC e protocolli off-chain

Oltre a Lightning, ANYPREVOUT può abilitare altri schemi avanzati:

• Vault: depositi con percorso di spesa vincolato. Con APO un utente può preparare transazioni di emergenza pre-firmate (ANYPREVOUT) da usare su futuri depositi. In caso di attacco, queste transazioni possono essere pubblicate e agganciate a qualunque UTXO nel vault, spostando i fondi su un wallet sicuro (magari via timelock) prima che l'attaccante li spenda. È stato dimostrato che il design di un semplice vault basato su CTV può essere realizzato anche con APO.

• Discrete Log Contracts (DLC): contratti a esito multiplo garantiti da oracoli. Usando APO, i partecipanti possono evitare di pre-firmare migliaia di transazioni per ogni esito: basta preparare output standard e poche transazioni ANYPREVOUT riutilizzabili per coprire molti scenari, riducendo drasticamente il numero di firme necessarie​.

• Payment Pool (CoinPool): protocolli in cui più utenti condividono un UTXO - basti pensare ad ARK - e aggiornano off-chain le rispettive quote. ANYPREVOUT consentirebbe di aggiornare lo stato delle pool e la distribuzione interna dei fondi in modo flessibile: ad esempio, se un membro esce dalla pool, gli altri possono reindirizzare le sue uscite con una transazione ANYPREVOUT invece di dover chiudere l'intera pool.

Tra miglioramenti al LN e rischi di “replay”

Argomentazioni a favore

I sostenitori di APO sottolineano che è un miglioramento molto utile e non invasivo. È opt-in e retrocompatibile, quindi chi non lo usa non subisce alcun effetto, mentre chi lo adotta ottiene immediatamente vantaggi: ad esempio, protocolli off-chain più semplici e meno dati da gestire. Il Lightning Network beneficerebbe di canali aggiornabili più facilmente, con backup più sicuri e meno rischi di errori catastrofici. In varie discussioni pubbliche lo spirito generale è favorevole: molti sviluppatori LN e ricercatori supportano l'adozione di ANYPREVOUT e ritengono che i benefici superino di molto i rischi residui​.

Argomentazioni contrarie

Il rischio più menzionato è quello di “replay”: se un utente spende con ANYPREVOUT e poi riceve nuovamente sulla stessa chiave, una sua vecchia firma potrebbe essere riutilizzata da un attaccante per rubare i nuovi fondi​.

Uno scenario potrebbe essere il seguente:

1. Hai usato una chiave pubblica (un “indirizzo”) per costruire un contratto Lightning che prevede l’uso di una firma ANYPREVOUT;

2. In quel contesto, hai generato e firmato in anticipo una transazione con ANYPREVOUT;

3. Poi, magari mesi dopo, riusi quella stessa chiave pubblica per ricevere nuovi fondi — magari in un altro wallet, o perché ti dimentichi di averla già usata.

A quel punto, se quella firma ANYPREVOUT che hai prodotto in passato finisce nelle mani sbagliate (ad esempio perché il tuo vecchio stato di canale viene pubblicato), quella firma può essere riusata per spendere i nuovi fondi ricevuti sulla stessa chiave pubblica.

In pratica, errori come il riuso di indirizzi diventerebbero più pericolosi.

Inoltre, alcuni sviluppatori temono di sprecare l'opportunità di un soft-fork: sarebbe preferibile introdurre una soluzione più generale che copra anche le funzionalità di APO (magari combinando nuovi opcodes) invece di dover fare un'altra attivazione in futuro​. Finora questi timori, uniti all'assenza di un champion dedicato, hanno mantenuto ANYPREVOUT in standby.