Ramo di Merkle Taproot

Ogni hash del ramo è un fratello del taptree, in ordine dalla tua foglia verso l'alto fino alla radice. Il BIP-341 limita il ramo a 128 hash, 4.096 byte, e il suo albero ordinato fa sì che il ramo non porti alcun bit di direzione sinistra o destra. La lunghezza del tuo ramo è pubblica, quindi una foglia più profonda rivela la profondità minima del tuo albero e suggerisce quale wallet ha costruito l'output.

Come funziona

Un ramo di Merkle Taproot viaggia dentro il control block, l'ultimo elemento nello stack del witness di una spesa tramite script path una volta rimosso l'eventuale annex.

Il control block ha una forma fissa. Il byte zero porta la versione della foglia più la parità della coordinata Y della chiave dell'output. I byte da 1 a 32 contengono la chiave pubblica interna. Tutto ciò che segue è il ramo: m hash consecutivi da 32 byte, quindi il control block misura 33 + 32m byte, e m deve essere un intero da 0 a 128. Qualsiasi altra lunghezza fa fallire la spesa prima che venga eseguito un solo opcode.

La verifica parte dal basso. Un nodo calcola l'hash dello script rivelato con il tag TapLeaf, poi incorpora a turno ogni hash del ramo con il tag TapBranch, confrontando a ogni passo i due valori da 32 byte in ordine lessicografico e calcolando prima l'hash del minore. Ciò che ne esce è la radice del taptree, che viene sottoposta a hash con la chiave interna con il tag TapTweak, sommata al punto interno e confrontata con i 32 byte nell'output speso.

Quel confronto è l'intero trucco. Poiché il BIP-341 ordina i due figli prima di calcolarne l'hash, un ramo non dice mai da quale lato stesse un fratello: lo deduce il verificatore. La motivazione è netta sul perché: dice che al progetto non interessa la posizione di specifici script nell'albero, solo che siano effettivamente impegnati.

Il tetto di 128 è un limite di sicurezza e non un tetto arbitrario. La profondità in un albero impacchettato in modo ottimale si avvicina al logaritmo in base due di uno diviso la probabilità di una foglia, quindi una profondità di 129 significherebbe uno script con una probabilità d'uso inferiore a 1 su 2^128, che secondo il BIP-341 probabilmente si può eliminare del tutto. All'altro estremo, un taptree con una sola foglia ha m pari a 0, un ramo vuoto e un hash della foglia che è già la radice.

Dove lo vedi

I rami di Merkle Taproot compaiono in qualsiasi transazione che spende un output bc1p rivelando uno script invece di firmare con la chiave.

Il BIP-341 sviluppa un esempio su un albero di cinque foglie. A, B, C ed E sono hash TapLeaf e AB è un hash TapBranch sui primi due. Per spendere usando lo script D il control block porta C, poi E, poi AB: tre hash, 96 byte di ramo, un control block da 129 byte. E viene sottoposto a hash prima di CD quando quei due si combinano, perché E si ordina più in basso.

Il costo in privacy è ciò su cui pianificare. La sezione sulla sicurezza del BIP-341 dice che la profondità di uno script rivela la profondità minima dell'albero, il che suggerisce il wallet software che ha costruito l'output e aiuta l'analisi della catena a raggruppare gli indirizzi, e raccomanda di discostarsi dall'albero che le probabilità delle foglie darebbero. Il riuso delle foglie è l'altra trappola: spendere un output diverso può ripubblicare gli stessi hash del ramo, quindi due spese che condividono un fratello da 32 byte appaiono correlate.

Ramo di Merkle Taproot vs blocco Merkle

Un ramo di Merkle Taproot dimostra che uno script appartiene a un indirizzo; un blocco Merkle dimostra che una transazione appartiene a un blocco. Il ramo del taptree è critico per il consenso, ricalcolato da ogni nodo completo che convalida la spesa, e non dipende dalla posizione perché l'ordinamento ha eliminato la necessità di dire sinistra o destra. Una prova sull'albero delle transazioni di un blocco non può prendere in prestito quel trucco, dato che l'ordine delle transazioni sotto la radice di Merkle di un blocco è fisso e significativo, quindi deve portare anche il percorso oltre agli hash.