Signature script

Ogni input di una transazione punta a un output precedente e deve dimostrare di essere autorizzato a spenderlo. Bitcoin Core chiama questo campo scriptSig; su un input legacy pay-to-public-key-hash contiene una firma di 71 o 72 byte e una chiave pubblica di 33 byte, circa 107 byte in tutto. Dal SegWit quella prova di solito risiede altrove, ed è gran parte del motivo per cui un prelievo verso un indirizzo bech32 ti costa meno.

Come funziona

Il signature script viene eseguito per primo e lascia i suoi risultati sullo stack perché li consumi lo script dell'output. I due non vengono eseguiti come un unico programma unito: sono eseguiti in sequenza, con lo stack passato dall'uno all'altro, una separazione introdotta nel 2010 dopo che il progetto originale si era rivelato sfruttabile.

La policy di relay impone che questo campo non contenga altro che push di dati. Nessun condizionale, nessuna aritmetica, nessun opcode che esegua un lavoro. La restrizione esiste perché chi spende ha il controllo completo di questi byte, e lasciare che un attaccante esegua logica in ingresso riapre problemi che la rete ha chiuso molto tempo fa. Pay-to-script-hash rende la regola un requisito di consenso e non una preferenza, dato che il redeem script deve arrivare come ultimo push semplice.

La sua dimensione dipende interamente da ciò che sblocca. Un input legacy a chiave singola contiene una firma e una chiave. Un input SegWit annidato contiene esattamente 23 byte, un singolo push del witness program di 22 byte, e sposta tutto il resto nel witness. Un input nativo bech32 o bech32m non contiene nulla: il campo serializzato è un unico byte di lunghezza zero.

C'è un input il cui signature script non è la prova di nulla. L'unico input di una transazione coinbase non ha un output precedente da sbloccare, quindi il campo viene riutilizzato come spazio libero tra 2 e 100 byte e, dal BIP-34, deve iniziare con l'altezza del blocco. I miner vi hanno firmato messaggi, voti e scherzi dal 2009.

Dove lo vedi

Decodifica una qualsiasi transazione e ogni input mostra un oggetto scriptSig con una vista assembly e una vista esadecimale. Su un input SegWit nativo o Taproot entrambe sono stringhe vuote, mentre un campo witness separato contiene i dati, e questa asimmetria visiva è il modo più rapido per capire a colpo d'occhio quale formato di indirizzo abbia usato una vecchia transazione.

Spiega anche un episodio storico spesso frainteso. Poiché lo scriptSig era incluso nel calcolo dell'ID della transazione, un terzo poteva ricodificare una firma senza invalidarla e cambiare l'ID di una transazione già diffusa. Mt. Gox sospese i prelievi a febbraio 2014 e attribuì la colpa esattamente a questo comportamento, sebbene un'analisi accademica successiva della catena abbia rilevato che il volume delle transazioni manipolate era di gran lunga troppo esiguo per spiegare i bitcoin mancanti. SegWit chiuse la questione ad agosto 2017 togliendo del tutto i dati di sblocco dal calcolo dell'ID.

Signature script vs dati del witness

Un signature script e i dati del witness portano lo stesso tipo di prova, e SegWit ha spostato il compito dall'uno all'altro senza cambiare il significato di una firma. Le differenze che contano per te sono il prezzo e la permanenza. I byte del witness sono fatturati a un'unità di peso ciascuno, mentre i byte del signature script costano quattro, quindi la stessa spesa a chiave singola occupa circa 148 byte virtuali quando la prova viaggia nello scriptSig e circa 68 quando viaggia nel witness. I dati del witness restano anche fuori dall'ID della transazione, quindi l'identificatore di una spesa non può essere alterato in transito. Un input legacy usa ancora il vecchio campo, ed è per questo che i bitcoin fermi su un indirizzo che inizia con 1 costano silenziosamente di più da spostare ogni volta che li sposti.