Tapscript

Il BIP-342 lo definisce, e il byte di versione foglia 0xc0 contrassegna un ramo di un taptree come tapscript e non come qualcosa inventato in seguito. Rispetto al linguaggio di script usato in ogni altro caso, elimina il limite di 201 operazioni che non siano push e il tetto di dimensione dello script di 10.000 byte, e disattiva OP_CHECKMULTISIG. Se spendi un bitcoin Taproot rivelando uno script, questo è il linguaggio in cui è scritto quello script.

Come funziona

Una spesa tapscript consegna alla rete tre cose nello stack del witness: gli argomenti che lo script richiede, lo script stesso e un control block che dimostra che lo script appartiene all'indirizzo.

La verifica delle firme è cambiata per prima. OP_CHECKSIG e OP_CHECKSIGVERIFY ora si aspettano una chiave pubblica x-only di 32 byte e una firma Schnorr di 64 byte, o 65 byte quando viene aggiunto un tipo di sighash non predefinito. OP_CHECKMULTISIG e OP_CHECKMULTISIGVERIFY falliscono subito, e OP_CHECKSIGADD prende il loro posto.

La contabilizzazione delle risorse è cambiata per seconda, e questa è la parte con conseguenze reali. I vecchi contatori, 201 operazioni per script e un conteggio globale di sigop, non ci sono più. Ogni input riceve invece un budget di validazione che parte da 50 unità di peso più la dimensione del proprio witness, e ogni verifica di firma riuscita ne sottrae 50. Il lavoro di verifica si paga in byte, che è una regola più pulita di un conteggio fisso e significa che uno script può contenere tutte le chiavi per cui sei disposto a pagare.

Sono state lasciate aperte due porte per aggiornamenti futuri. Gli opcode 80, 98, 126 a 129, 131 a 134, 137, 138, 141, 142, 149 a 153 e 187 a 254 sono diventati OP_SUCCESS: se uno qualsiasi di essi compare in un punto qualsiasi dello script, anche in un ramo che non viene mai eseguito, lo script ha successo immediatamente. Le chiavi pubbliche di qualsiasi lunghezza diversa da 32 byte sono trattate come un tipo di chiave sconosciuto e vengono accettate. Entrambe le regole permettono a un successivo soft fork di assegnare un comportamento reale senza un hard fork. Ciò che è rimasto invariato è il limite di 520 byte per un singolo elemento dello stack e il limite di 1.000 elementi dello stack.

Dove lo vedi

Tapscript compare ogni volta che un output Taproot viene speso nel modo difficile, rivelando un ramo invece di firmare con la chiave aggregata.

L'utilizzatore reale più pesante è l'archiviazione di dati. Un'iscrizione ordinals è un envelope tapscript, una porzione di contenuto inserita 520 byte alla volta tra OP_FALSE OP_IF e OP_ENDIF, ed esiste in quella forma proprio perché tapscript ha eliminato il limite di 10.000 byte dello script e ha messo dietro di esso lo sconto sul witness. Qualunque cosa tu pensi di questa pratica, è il motivo per cui la maggior parte delle persone ha visto una spesa tapscript senza saperlo.

Gli usi più vicini a chi risparmia sono più discreti. I rami di recupero con timelock, i fallback di deposito a garanzia e gli script di canale più recenti di Lightning vivono tutti come foglie tapscript, e Bitcoin Core può costruirli e firmarli tramite Miniscript dentro un descrittore tr().

Tapscript vs Bitcoin Script

Bitcoin Script è la famiglia; tapscript ne è un membro. Sulla rete sono attive contemporaneamente tre versioni di script: il linguaggio legacy, il linguaggio della versione 0 di SegWit e tapscript, e un nodo sceglie tra loro in base all'output che viene speso, non in base a qualcosa nello script stesso.

Questo conta quando copi uno script da un tutorial. Un due su tre scritto con OP_CHECKMULTISIG è valido in un output P2WSH e non valido in una foglia di un taptree. Uno script che inserisce 4.000 byte supera il limite di consenso in uno script di witness P2WSH e va bene in tapscript. Gli stessi opcode sulla pagina, un regolamento diverso sotto.