OP_CHECKMULTISIG

Il byte 0xae è ciò che ha reso possibile la custodia condivisa: estrae dallo stack un conteggio di chiavi, altrettante chiavi pubbliche, un conteggio di firme richieste, altrettante firme e poi un elemento di troppo. Il consenso consente fino a 20 chiavi in una sola chiamata. È il motivo per cui una società può richiedere che tre su cinque dirigenti approvino un prelievo senza che nessuno di loro possa agire da solo.

Come funziona

La verifica è un unico passaggio su due elenchi, non una ricerca. L'opcode scorre le firme in ordine e prova ciascuna con le chiavi pubbliche successive, quindi le firme devono comparire nello stesso ordine relativo delle chiavi a cui appartengono. Presenta un valido 2-di-3 con le due firme scambiate e lo script fallisce, una causa frequente di confusione quando si compongono a mano i pagamenti multisig.

Lo stack resta con un elemento in meno, e lo è sempre stato. L'implementazione originale estraeva un elemento in più che non usava mai, un bug che non si poteva rimuovere senza rompere tutti i bitcoin esistenti. I firmatari hanno imparato a inserire prima un elemento usa e getta, e il BIP-147 ha chiuso la malleabilità che ne derivava imponendo che quell'elemento sia vuoto, dal blocco 481.824 in poi.

Il calcolo dei costi è il punto critico. Una chiamata semplice viene addebitata come 20 operazioni di firma a prescindere da quante chiavi contenga davvero, a meno che non la preceda immediatamente un opcode di numero piccolo, nel qual caso l'addebito è quel numero. Un blocco è limitato a 80.000 unità di costo di operazione di firma, e la policy di relay consente al massimo 15 di queste in un singolo input pay-to-script-hash. È quel numero della policy, non il limite di 20 dell'opcode stesso, il motivo per cui gli indirizzi script arrivano al massimo a quindici cofirmatari.

Tapscript lo ha ritirato del tutto. Il BIP-342 ha fatto sì che l'opcode e la sua variante verify falliscano appena compaiono dentro una foglia Taproot, perché verificare un lotto di firme Schnorr rispetto a un elenco in un'unica operazione annulla la verifica in batch che rende Schnorr utile.

Dove lo vedi

L'output 2-di-2 che finanzia ogni canale Lightning usa OP_CHECKMULTISIG, il che da solo colloca l'opcode in una larga parte dei pagamenti con script della rete. Lo usano anche le tesorerie aziendali, gli accordi di deposito a garanzia sui marketplace peer-to-peer più vecchi e la cold storage degli exchange costruita prima di Taproot, di solito come 2-di-3 dentro un hash di script.

Le chiamate semplici, in cui le chiavi stanno direttamente nell'output senza alcun hash davanti, sono standard per il relay fino a tre chiavi e non vengono quasi mai usate, perché il mittente paga per ogni chiave e l'intera configurazione è pubblica prima che si muova un solo bitcoin. Nel 2014 quel formato è diventato per breve tempo un modo per archiviare file sulla catena, e questo è in parte il motivo per cui le discussioni sull'archiviazione dei dati riemergono ogni volta che qualcuno tocca la policy di relay.

Se stai impostando ora una custodia condivisa, è più probabile che il tuo wallet produca una configurazione Taproot con l'alternativa a conteggio, oppure uno script P2WSH se la compatibilità conta più delle commissioni.

OP_CHECKMULTISIG vs multisig P2SH

OP_CHECKMULTISIG è un'istruzione e il multisig P2SH è un modo di impacchettarla. L'opcode dice come si verifica un quorum; il pacchetto dice che il quorum è nascosto dietro un hash e viene rivelato al momento del pagamento. La stessa istruzione può comparire in un output semplice con le chiavi in bella vista, in un redeem script dietro un indirizzo che inizia con 3, oppure in un witness script dietro un indirizzo bc1q, e i tre casi differiscono enormemente per costo e privacy pur eseguendo una logica di verifica identica. Quello che non puoi fare è usare l'istruzione in una foglia Taproot, ed è per questo che i quorum moderni si costruiscono con un opcode del tutto diverso.