Dati witness

Ogni input riceve il proprio witness: una pila di elementi, il più delle volte una firma e una chiave pubblica. La sezione sta dopo gli output, dietro un marcatore e un flag di due byte che segnalano al software che la transazione è nel formato più recente. Un nodo che esegue software precedente all'aggiornamento del 2017 non la chiede mai e non la vede mai.

Come funziona

I dati witness hanno un posto proprio nella disposizione in byte di una transazione, definito dal BIP-144.

Una transazione serializzata nel formato più recente si legge così: versione, il byte marcatore 0x00, il byte flag 0x01, gli input, gli output, poi una pila witness per ogni input nello stesso ordine, infine il locktime. Il marcatore è il punto in cui si trova il trucco di compatibilità, perché un valore pari a zero significherebbe zero input per il parser vecchio, il che non ha senso, quindi il software vecchio che riceve il nuovo formato capisce subito che non è per lui e ai peer legacy non viene semplicemente mai inviato.

Da qui derivano due identificatori. Il txid è un doppio SHA-256 della transazione con marcatore, flag e witness rimossi, ed è per questo che nulla dentro un witness può modificarlo. Il wtxid calcola invece l'hash della serializzazione completa. Ogni blocco fissa una radice di merkle dei suoi wtxid dentro un output coinbase, un OP_RETURN il cui script misura almeno 38 byte e inizia con il tag di quattro byte 0xaa21a9ed, così i dati sono protetti anche se vivono fuori dal vecchio commitment.

Il costo è il punto in cui si vede lo sconto. Tutto ciò che sta fuori dal witness costa quattro unità di peso per byte e tutto ciò che sta dentro ne costa una, con un tetto di 4.000.000 unità di peso per blocco. Dividi il peso per quattro e ottieni i byte virtuali, l'unità in cui si esprimono le commissioni.

Dove lo vedi

Apri una transazione qualsiasi su un block explorer e dimensione, dimensione virtuale e peso saranno stampati uno accanto all'altro. Quando non coincidono, la differenza è il witness. Un pagamento senza alcun witness mostra una dimensione uguale al suo vsize; un pagamento Taproot può mostrare un vsize appena un quarto della sua dimensione grezza.

Espandendo un singolo input su un explorer moderno si vede la pila stessa. Per un pagamento bc1q sono due elementi, una firma di circa 71 o 72 byte e una chiave pubblica compressa di 33 byte, mentre per una spesa lungo il percorso di chiave Taproot è un solo elemento di esattamente 64 byte. Quel conteggio è l'intera ragione per cui i tipi di output più recenti costano meno da spendere.

Il campo compare anche nei file che gestisce il tuo wallet hardware. Una transazione bitcoin parzialmente firmata ha, per ogni input, un record UTXO witness e un record witness finale, ed è ciò che un'app coordinatrice si scambia mentre una transazione multisig raccoglie le firme.

Dati witness vs script witness

I dati witness sono l'intera pila; uno script witness è un elemento al suo interno. Per una spesa P2WSH, l'ultimo elemento della pila è lo script il cui hash è stato fissato dall'output, e tutto ciò che lo precede esiste per soddisfare quello script. Il rapporto ripete esattamente lo schema più vecchio, in cui un redeem script è l'ultimo elemento di uno script di firma P2SH. Quindi ogni script witness è un dato witness, mentre la maggior parte dei dati witness, compresa ogni ordinaria spesa a chiave singola, non contiene alcuno script witness.