Glossario / Transazioni e commissioni
Transazione TRUC
Noto anche come transazione v3, Topologically restricted until confirmation.
- Che cos'è una transazione TRUC?
- Una transazione TRUC scambia la libertà di concatenare spese non confermate con un aumento affidabile della commissione, dichiarando la versione 3 e accettando al massimo una transazione madre non confermata e una figlia non confermata.
Specificato nel BIP-431.
TRUC è una politica di relay che un mittente sceglie impostando la versione di una transazione a 3, non una regola di consenso. Bitcoin Core 28.0 l'ha resa standard secondo il BIP 431, che limita la transazione a 10.000 byte virtuali e la sua transazione figlia a 1.000. Non sarai tu a impostarla: il BIP 431 indirizza la politica verso protocolli come Lightning, le cui transazioni di impegno sono firmate in anticipo e ricevono l'aumento di commissione al momento della diffusione.
Come funziona
TRUC è composta da sei regole aggiunte a una transazione ordinaria, e un mittente le attiva tutte e sei insieme impostando il campo della versione a 3.
La regola uno rende la transazione sostituibile indipendentemente dal fatto che segnali o meno secondo il vecchio metodo del BIP125, una distinzione che quella stessa versione ha comunque reso superflua adottando per impostazione predefinita il replace-by-fee completo. La regola due rende la scelta permanente: ogni antenato non confermato di una transazione TRUC deve essere TRUC, e ogni discendente non confermato di una transazione TRUC non confermata deve essere TRUC a sua volta, così nessuno elude i limiti agganciando una transazione figlia ordinaria, anche se gli output confermati sono esenti in entrambe le direzioni. La regola tre è la restrizione da cui viene il nome: un antenato non confermato e un discendente non confermato, senza l'eccezione CPFP (CPFP carve out). La regola quattro limita la transazione a 10.000 byte virtuali, contro il tetto di standardità di 100.000 per tutto il resto. La regola cinque limita la transazione figlia a 1.000 byte virtuali, il che con input taproot lascia comunque spazio per 15 input e 2 output. La regola sei consente alla transazione di stare sotto la commissione minima di relay del nodo, anche a zero, purché il pacchetto intorno a essa paghi abbastanza.
Il motivo di tutto ciò è il pinning: la spazzatura di qualcun altro che rende impossibile aumentare la commissione della tua transazione. Le regole di sostituzione chiedono a una sostituzione di pagare una commissione assoluta maggiore di quella di tutte le transazioni che sostituisce, e rifiutano in blocco qualsiasi sostituzione che espellerebbe più di 100 transazioni. Il BIP 431 quantifica quanto sia facile abusarne. Se vuoi sostituire cinque tue transazioni e una controparte ha agganciato 21 discendenti a ciascuna, la tua sostituzione viene rifiutata solo in base al conteggio, qualunque cosa paghi. Chi può agganciare discendenti economici alla tua transazione non confermata stabilisce il prezzo del tuo stesso aumento di commissione.
Il limite di 1.000 byte virtuali per la transazione figlia è la risposta diretta a questo. Con i limiti predefiniti sui discendenti, una transazione figlia che aumenta la commissione può essa stessa occupare 100.000 byte virtuali, e a un satoshi per byte virtuale ciò significa 100.000 satoshi o più che una sostituzione deve coprire prima di competere nel merito. Limitare la transazione figlia a 1.000 riduce il limite superiore di un fattore cento.
Due meccanismi accompagnano le regole. L'espulsione tra sorelle consente a un nodo che riceve una seconda transazione figlia che paga meglio di espellere la prima secondo le regole di sostituzione, invece di rifiutare la nuova arrivata, e poiché può esistere una sola figlia non c'è da indovinare quale scartare. Il replace-by-fee dei pacchetti, che Bitcoin Core 28.0 ha abilitato per gruppi connessi di dimensione due, funziona quindi sulle transazioni TRUC perché quella forma è garantita.
Perché questo conta quando compri bitcoin
TRUC raggiunge un normale proprietario di bitcoin in un solo momento: quando un canale Lightning deve essere chiuso on-chain e la commissione deve essere aumentata dopo che la transazione è stata firmata.
Non è all'acquisto che si fa sentire. Delle 41 recensioni di wallet su questo sito, quelle che mettono un vero nodo Lightning sul tuo smartphone sono quelle in cui la politica smette di essere una curiosità. Phoenix, di ACINQ, è valutato 4,0 qui e gestisce un nodo autonomo protetto da una frase di recupero di 12 parole, e il percorso di emergenza che ACINQ documenta consiste nel forzare la chiusura, attendere circa 720 blocchi, all'incirca cinque giorni, e recuperare i fondi on-chain con uno strumento come Electrum. Quella chiusura diffonde una transazione di impegno, che il BIP 431 indica come quella che si appoggia all'eccezione CPFP per evitare il pinning. Una transazione di impegno che non riesce a entrare in un blocco prima della scadenza di un termine non resta semplicemente lì: il denaro che proteggeva diventa reclamabile dall'altra parte.
La custodia sposta l'esposizione, ed è questa la differenza tra le nostre schede. Strike, valutato 4,6, ti consente di prelevare tramite Lightning e non aggiunge commissioni proprie sui trasferimenti, ma i saldi sono in custodia finché restano nell'app, quindi i canali e le loro chiusure appartengono a Strike. Muun, valutato 3,8, mostra on-chain e Lightning come un unico saldo e passa dall'uno all'altro con gli swap sottomarini. Quanto più possiedi davvero una parte di un canale, tanto più un aumento di commissione affidabile diventa un tuo problema, e TRUC è la politica scritta per fornirlo all'interno dell'insieme di nodi che la eseguono.
Una chiusura forzata di Phoenix, con e senza pinning
Una chiusura forzata di Phoenix è il punto più chiaro per vedere TRUC fare il suo lavoro, perché la transazione diffusa è stata firmata molto prima che qualcuno sapesse come sarebbe stato il mercato delle commissioni.
Prendi prima la vecchia configurazione. La tua transazione di impegno è una transazione ordinaria che non dichiara la versione 3, diffusa con una transazione figlia che paga per entrambe. La tua controparte detiene il secondo output anchor, che esiste perché entrambe le parti possano aumentare la commissione, e lo usa per agganciare una propria transazione figlia di 100.000 byte virtuali che paga un satoshi per byte virtuale. Nulla di ciò che ha fatto è invalido. L'eccezione CPFP ti permetteva di far passare una transazione figlia in più oltre il limite sui discendenti, ma alle regole di sostituzione non importa: sostituire la sua transazione figlia significa pagare i 100.000 satoshi di commissione che già porta prima che la tua commissione conti qualcosa, e l'eccezione concedeva esattamente una transazione figlia in più, quindi falliva nel momento in cui un terzo partecipava alla transazione. La tua chiusura è bloccata dal pinning per colpa di spazzatura che al suo autore è costata quasi nulla.
Ora imposta entrambe le transazioni alla versione 3. Alla transazione di impegno è consentito non pagare nulla, perché la regola sei la accetta sotto il minimo di relay purché il pacchetto superi la soglia, che è ciò di cui ha bisogno una transazione firmata con mesi di anticipo. Può esistere una sola transazione figlia, e non può superare 1.000 byte virtuali, quindi il conto peggiore che qualcuno può presentarti è un centesimo di quello vecchio. Se la controparte riesce a inserire prima la sua transazione figlia, la tua la espelle pagando di più. E la coppia viaggia come un'unità, perché Bitcoin Core 28.0 ha introdotto nella stessa versione il relay dei pacchetti con una transazione madre e una figlia, con le transazioni madre TRUC ammesse sotto la commissione minima di relay.
L'avvertenza onesta è l'adozione. Il BIP 431 afferma che il beneficio contro il pinning è limitato alla mempool di un singolo nodo, e quanto sia sicura la tua transazione dipende da quanta parte della rete esegue la politica. La versione 3 non era standard prima di Bitcoin Core 28.0, quindi un nodo ancora su una versione precedente non la trasmetterà affatto, e le note di rilascio definiscono quel nuovo relay dei pacchetti limitato e non ancora affidabile in condizioni ostili.
Transazione TRUC vs numero di versione della transazione
Il numero di versione della transazione è un campo che ogni transazione bitcoin porta, e TRUC è l'insieme di regole che un valore di quel campo ora assicura.
Impostare la versione a 3 è il modo in cui un mittente sceglie TRUC, ma le regole non risiedono nel campo. È un indicatore; tutto ciò che conta avviene nel codice di politica di un nodo, ed è per questo che un nodo aggiornato trasmette la transazione che uno più vecchio rifiuta. Il consenso non ha mai preso posizione in un senso o nell'altro. Il BIP 431 riporta che la versione 3 in precedenza non era standard e non aveva conflitti noti con usi precedenti, quindi ciò che è cambiato in Bitcoin Core 28.0 è stata la trasmissibilità, non la validità.
Transazione TRUC vs cluster mempool
Il cluster mempool applica limiti di topologia a ogni transazione nella mempool di un nodo, mentre TRUC ne applica di molto più stretti solo alle transazioni che li richiedono.
I due sono lavori correlati, non rivali, e il BIP 431 lo dice direttamente: il cluster mempool limita la dimensione del cluster per tutte le transazioni, non solo per quelle che scelgono TRUC, ed è molto meno restrittivo dei limiti di TRUC. Lascia anche lacune che il BIP 431 nomina: il cluster mempool non risolve il pinning tramite le commissioni assolute né tramite il numero di conflitti, ed è incompatibile con l'eccezione CPFP su cui si appoggiava il vecchio design dei canali Lightning. TRUC, l'espulsione tra sorelle e la sostituzione dei pacchetti sono la strada offerta ai protocolli che vi facevano affidamento.