OP_CHECKSIGADD

L'opcode prende tre elementi dallo stack, una firma, un conteggio progressivo e una chiave pubblica, e ripone il conteggio invariato oppure aumentato di uno. BIP-342 gli ha assegnato l'opcode 186 e, nello stesso momento, ha disattivato OP_CHECKMULTISIG, così ogni multisig negli script Taproot si scrive in questo modo. Il vantaggio pratico è che una policy a soglia non si ferma più a 20 chiavi.

Come funziona

Una soglia in tapscript è una catena di verifiche di firma con un conteggio che passa dall'una all'altra, e un confronto alla fine.

Scritto per esteso, un due su tre si legge così: inserisci la prima chiave pubblica, OP_CHECKSIG, inserisci la seconda, OP_CHECKSIGADD, inserisci la terza, OP_CHECKSIGADD, inserisci 2, OP_NUMEQUAL. L'esecuzione procede da sinistra a destra. OP_CHECKSIG lascia sullo stack 1 o 0, e ogni OP_CHECKSIGADD estrae una chiave pubblica, estrae quel totale progressivo, estrae la firma offerta per questa chiave e ripone il totale aggiungendo 1 se la firma è stata verificata. Il confronto finale decide se ne sono state verificate abbastanza.

Un firmatario che non partecipa fornisce una stringa di byte vuota al posto di una firma. L'opcode la vede, tratta lo slot come non firmato e restituisce il conteggio intatto, il che costa un solo byte nel witness. È tutto il meccanismo, e rimuove l'elemento fittizio dello stack che OP_CHECKMULTISIG richiedeva a causa di un errore di off-by-one nell'implementazione originale.

Dal verificare una chiave contro una firma derivano due conseguenze. La verifica diventa eseguibile in batch: un nodo può riunire tutte le firme Schnorr del blocco in un'unica verifica aggregata invece di provare le chiavi candidate in ordine, il che è gran parte dell'accelerazione della validazione di Taproot. E il numero di chiavi è limitato dal budget di validazione di tapscript, che spende 50 unità di peso per ogni firma verificata, non da un tetto fisso scritto nell'opcode.

Dove lo vedi

OP_CHECKSIGADD compare in qualsiasi script Taproot che richieda più di un firmatario, il che nel software dei wallet di solito significa un descriptor e non uno script grezzo.

Bitcoin Core lo espone come frammenti multi_a e sortedmulti_a dentro un descriptor tr(), così un quorum a tre chiavi si scrive come tr(internalkey,multi_a(2,KEY1,KEY2,KEY3)) e il software genera per te la catena di opcode. Miniscript lo tratta allo stesso modo, e i dispositivi hardware che gestiscono policy Taproot firmano questi script senza bisogno di conoscere in anticipo la disposizione.

Il design cambia anche il modo in cui puoi costruire un quorum. Invece di una sola foglia che contiene tutte e tre le chiavi, un taptree può contenere tre foglie separate, ognuna con due chiavi, una per ogni possibile coppia, e una spesa rivela poi solo la coppia che ha effettivamente firmato. Questo costa di più in foglie di script e risparmia una chiave pubblica nel witness, ed è un vero miglioramento della privacy rispetto a pubblicare l'intero insieme di chiavi a ogni spesa.

OP_CHECKSIGADD vs OP_CHECKMULTISIG

OP_CHECKSIGADD e OP_CHECKMULTISIG contano entrambi le firme rispetto a un insieme di chiavi, e solo uno dei due funziona in una foglia Taproot. OP_CHECKMULTISIG resta perfettamente valido negli script legacy e SegWit versione 0, quindi il multisig bc1q che la gente usa da anni non è toccato e non richiede alcuna migrazione.

Dentro tapscript, OP_CHECKMULTISIG e OP_CHECKMULTISIGVERIFY sono disattivati del tutto. Oltre al contesto, contano tre differenze: il vecchio opcode limita uno script a 20 chiavi pubbliche e quello nuovo non ha tale numero, il vecchio richiede un elemento fittizio in più sullo stack che BIP-147 in seguito ha imposto vuoto come regola di consenso, e il vecchio non può essere verificato in batch perché un verificatore non sa in anticipo a quale chiave appartiene ogni firma.