OP_CHECKTEMPLATEVERIFY

Il BIP-119 lo descrive, Jeremy Rubin ha pubblicato la prima bozza a gennaio 2020 e la rete non lo ha adottato. L'opcode prenderebbe dalla pila un hash di 32 byte e farebbe fallire lo script se un hash del template della transazione che spende, cioè la sua versione, il suo locktime, il numero di input, le sequenze, gli output e l'indice dell'input, non coincide. Nulla nel tuo wallet lo usa, e nulla lo farà finché un soft fork non lo attiverà.

Come funziona

Stato: proposto, non attivato. Il BIP-119 è una bozza dal 2020, un'attivazione proposta nel 2022 ha raccolto obiezioni sufficienti per essere accantonata e Bitcoin Core non contiene parametri di attivazione per questo opcode.

Il progetto riusa un vecchio espediente di aggiornamento. L'opcode 179, prima OP_NOP4, attualmente non fa nulla, quindi uno script che lo contiene è valido per ogni nodo della rete. Un soft fork ridefinirebbe quel byte in modo che i nodi aggiornati eseguano il controllo mentre quelli vecchi continuano a lasciar passare lo script, lo stesso percorso che ha seguito CLTV con OP_NOP2 e CSV con OP_NOP3.

Ciò che finisce nell'hash è scelto con una cura insolita. Il template copre gli output, gli importi, il numero di input e i loro numeri di sequenza, ma lascia deliberatamente fuori gli outpoint, cioè i txid dei bitcoin spesi. Lasciarli fuori ha due conseguenze su cui si regge tutta la proposta. Primo, puoi calcolare l'hash prima che esista la transazione di finanziamento, ed è questo che permette di costruire una catena di spese future e poi finanziarla. Secondo, un template non può contenere un vincolo su se stesso, quindi la restrizione non può essere fatta ripetere all'infinito, ed è per questo che i suoi sostenitori lo chiamano il covenant ristretto.

Il risultato è una spesa il cui txid è noto prima che avvenga. Un wallet può consegnarti una ricevuta di un pagamento che esisterà più avanti e dimostrare che nessun'altra spesa di quel bitcoin è possibile.

Dove lo vedi

OP_CHECKTEMPLATEVERIFY non viene eseguito in nessun punto della mainnet, quindi il posto da guardare è l'insieme delle applicazioni costruite su signet personalizzate che verrebbero rilasciate se l'opcode si attivasse.

Il controllo della congestione è il più citato. Un exchange che affronta un picco di commissioni paga 1.000 prelievi in un solo output che vincola un albero di pagamenti successivi; ogni utente può poi espandere il proprio ramo e ricevere i fondi quando le commissioni scendono, e l'exchange ha speso un output invece di mille. I vault sono al secondo posto: un prelievo deve prima arrivare a un output di transito con un ritardo, dandoti una finestra per riportare i fondi nella cold storage se la richiesta non era tua. I pool di pagamento e il finanziamento non interattivo dei canali Lightning usano la stessa forma: vincolare prima, espandere dopo.

Per chi compra bitcoin, la posizione onesta è che questo non cambia nulla su cui tu possa agire. Vale la pena riconoscere la sigla perché compare costantemente nei dibattiti su cosa dovrebbe diventare bitcoin, e perché le funzioni di vault che alcuni servizi di custodia pubblicizzano sarebbero davvero azionabili se l'opcode si attivasse.

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY vincola la forma della transazione che spende, mentre OP_CHECKLOCKTIMEVERIFY vincola quando una spesa può avvenire e non dice nulla su dove vanno i fondi. I nomi quasi identici fanno sì che i due vengano continuamente confusi.

L'altra differenza è lo stato, ed è quella che conta. OP_CHECKLOCKTIMEVERIFY è applicato dal blocco 388.381 del 14 dicembre 2015 ed è usato ogni giorno da Lightning, dagli script di deposito a garanzia e dai wallet di eredità. OP_CHECKTEMPLATEVERIFY non è mai stato applicato da un solo nodo sulla mainnet. Se un servizio ti dice che i tuoi bitcoin sono protetti da un vincolo di template, sta descrivendo qualcosa che la rete attualmente non verifica.