Annesso di Taproot

Il BIP-341 ha riservato il campo per future soft fork e non gli ha attribuito alcun significato, quindi oggi nessun nodo ne legge il contenuto. IsWitnessStandard di Bitcoin Core rifiuta una spesa Taproot che contenga un annesso contrassegnato con 0x50, quindi la transazione non verrà propagata, e il BIP-341 avverte che può portare alla perdita permanente dei fondi. I wallet non hanno motivo di aggiungerne uno, quindi nulla di ciò che fai quando compri o detieni bitcoin dipende da esso.

Come funziona

Un annesso di Taproot si identifica per posizione, non tramite un campo denominato nel formato della transazione. Se un input Taproot contiene almeno due elementi nel witness e il primo byte dell'ultimo elemento è 0x50, quell'elemento è l'annesso e viene rimosso dallo stack del witness prima di esaminare qualsiasi altra cosa. Solo allora un nodo decide cosa ha davanti: un elemento rimanente significa una spesa tramite key path, due o più significano una spesa tramite script path.

Il BIP-341 ha scelto 0x50 di proposito. Le versioni di foglia vanno in coppie pari e dispari che non devono essere confuse con il primo byte di un witness P2WPKH o P2WSH, e 0x50 era un valore spaiato rimasto libero, quindi era quello che costava meno future versioni di script. La regola vale anche al contrario: una versione di foglia non può essere 0x50, perché un blocco di controllo che iniziasse con quel byte sarebbe indistinguibile da un annesso.

Ciò che l'annesso non fa è influenzare la validazione. Il BIP-341 dice che il campo "is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation". Ogni messaggio di firma Taproot porta uno spend_type di un byte pari a (ext_flag * 2) + annex_present e, quando un annesso è presente, il messaggio porta anche sha_annex, lo SHA256 da 32 byte del prefisso di lunghezza dell'annesso e dell'annesso stesso, byte 0x50 compreso. L'assenza è firmata con la stessa fermezza della presenza, quindi nessuno può aggiungere un annesso alla tua transazione nella mempool né rimuoverne uno. Il BIP-341 fissa il messaggio di firma a 174 byte, meno 49 per ANYONECANPAY, meno 32 per NONE, più 32 quando è presente un annesso, con un massimo di 206.

Dove lo vedi

Un annesso di Taproot non si vede nell'uso ordinario, ed è il design che funziona. La policy di propagazione di Bitcoin Core, in src/policy/policy.cpp, controlla ogni input con versione witness 1 e programma da 32 byte e restituisce false quando il witness contiene due o più elementi e l'ultimo inizia con la costante ANNEX_TAG, definita come 0x50 in src/script/script.h. Il commento accanto a quel controllo è tutta la policy: "Annexes are nonstandard as long as no semantics are defined for them." Una transazione che ne contenga uno è valida per consenso e in pratica non recapitabile: un nodo predefinito la scarta invece di propagarla.

Un annesso compare davvero in un solo posto, in ogni firma Taproot che tu abbia mai creato, il cui spend_type porta un bit a zero che dice che qui non c'è alcun annesso. È quell'impegno che renderebbe utilizzabile un soft fork futuro: il BIP-341 indica come scopo previsto segnalare il costo di validazione di nuovi e costosi opcode senza che un nodo debba recuperare l'output speso.

Annesso di Taproot vs OP_RETURN

OP_RETURN è lo spazio che bitcoin designa per pubblicare byte che nessuno spenderà, e l'annesso di Taproot non è affatto uno spazio di pubblicazione. Entrambi vengono descritti come spazio per dati che il consenso ignora, e si comportano in modi opposti. I dati OP_RETURN risiedono in un output, fanno parte della transazione che ogni nodo valida e annunciano un unico significato concordato: qui non c'è nulla di spendibile. I byte dell'annesso risiedono nel witness, vengono rimossi prima che lo stack sia letto e portano un avvertimento della specifica stessa, che "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS."

Quell'avvertimento non è un ornamento. Un soft fork può solo aggiungere regole, quindi byte ignorati oggi possono essere rifiutati domani, e la tua firma copre l'annesso, quindi non puoi rimuoverlo da una transazione già firmata. Chi prefirma spese con anni di anticipo, come fa un vault o un canale Lightning, vincolerebbe un campo il cui significato nessuno ha ancora scritto.