Questo è un editoriale di opinione di Shinobi, un educatore autodidatta nello spazio Bitcoin e host di podcast Bitcoin orientato alla tecnologia.
Grande sorpresa, i Bitcoiners stanno discutendo furiosamente su una proposta set di modifiche da includere nella prossima versione di Bitcoin Core. Opt-in replace-by-fee (RBF) è una funzionalità dei criteri di mempool che è stata proposta nel 2015 per offrire agli utenti uno strumento per far fronte a rapidi picchi di commissioni che portano le loro transazioni a rimanere bloccate non confermate nel mempool per lunghi periodi di tempo.
Ovviamente, questo sarà un problema per qualsiasi utilizzo di Bitcoin se il volume delle transazioni cresce in media per essere costantemente superiore al numero di transazioni che possono essere elaborate nella blockchain, quindi a meno che tu non pensi che non accadrà mai questa è una funzionalità necessaria sulla rete.
La sostituzione della transazione era effettivamente inclusa e possibile nella versione originale del software prima della scomparsa di Satoshi Nakamoto. Alla fine ha disabilitato la funzione perché il modo in cui l’ha implementata originariamente ha creato un vettore per attacchi denial-of-service contro i nodi. La sua implementazione ha consentito la sostituzione di qualsiasi transazione senza pagare una commissione più elevata, il che essenzialmente avrebbe consentito agli utenti di inviare una transazione e quindi iniziare a trasmettere un numero illimitato di sostituzioni alla rete. Ciò consentirebbe ovviamente lo spamming di nodi con enormi quantità di dati che non richiedono prove di lavoro e aumenterebbe in modo proibitivo il costo di esecuzione di un nodo.
Nel corso degli anni alcune diverse proposte per una sostituzione delle transazioni rinnovata e più sicura schema sono stati discussi. Analizzeremo rapidamente tutto questo.
RBF completo
La variante più semplice di RBF. Qualsiasi transazione può essere sostituita a condizione che la sostituzione della transazione originale stia pagando una commissione maggiore di quella che sta sostituendo. In questo modo le transazioni sono tutte sostituibili, ma l’obbligo di pagare una commissione più alta ogni volta che ne si sostituisce una impedisce uno spam infinito di nuove versioni dei nodi di sovraccarico delle transazioni.
RBF First-Seen-Safe
Questo proponeva di consentire la sostituzione di tutte le transazioni nel mempool, con un avvertimento speciale; tutti gli output della transazione originale devono essere inclusi anche nella transazione di sostituzione, compreso l’output di modifica. Richiede comunque l’aumento della commissione per sostituire una transazione, ma il requisito di mantenere gli stessi output significa che devi aggiungere un nuovo input e un secondo output di modifica, poiché nessuno degli output originali può essere modificato. Ciò si traduce in transazioni più grandi che devono pagare di più in totale per garantire che la sostituzione paghi una tariffa più alta.
RBF ritardato
Ecco una proposta per consentire la sostituzione di qualsiasi transazione nel mempool, ma solo dopo che un certo numero di blocchi era passato da quando il nodo ha visto la transazione originale. L’idea era che ciò avrebbe consentito di sostituire e confermare più rapidamente le transazioni bloccate in ambienti con commissioni elevate, ma il ritardo di sostituzione avrebbe impedito tentativi di doppia spesa con conferma zero.
Opt-In RBF
Questo è ciò che è stato implementato nel 2016 come definito in BIP 125. Le transazioni possono essere sostituite solo se hanno impostato un flag specifico nella transazione optando per la sostituzione, o se uno dei loro antenati lo ha fatto nel caso di una catena di transazioni non confermate, per consentire alle persone che ricevono fondi di sapere se una transazione non confermata sarà o meno sostituibile nel mempool.
La grande controversia di oggi è che la prossima versione di Core, 0.24, introdurrà un flag di policy di mempool RBF completo. Cosa significa questo? Offrirà agli utenti un’opzione configurabile per modificare la loro politica di mempool locale da RBF opt-in a RBF completo; per impostazione predefinita l’opzione sarà disattivata (i nodi utilizzeranno l’RBF completo). Allora perché le persone sono in armi per questo cambiamento? Le aziende che accettano transazioni a conferma zero dipendono dalla stragrande maggioranza dei mempool dei nodi che si rifiutano di sostituire le transazioni che non hanno attivato RBF con un flag di transazione. Lo fanno collegando tatticamente il loro nodo a un gran numero di altri nodi sparsi in tutta la rete. Ciò consente loro di rilevare molto rapidamente la presenza di una transazione a doppia spesa sulla rete, poiché deve essere eseguita quasi immediatamente se una transazione non è contrassegnata come RBF per avere buone possibilità di farcela ai minatori. Vale anche la pena sottolineare che ogni azienda sulla rete non può farlo senza sybiling la rete. Queste aziende affermano che l’RBF completo”rompe”il loro modello di business di utilizzo dell’RBF. Alcuni hanno persino criticato gli sviluppatori principali in quanto”forzano”un cambiamento che influisca negativamente su queste attività.
La semplice realtà è che la doppia spesa è e sarà sempre possibile, opt-in RBF o full RBF non fa nulla per cambiare questo. Inoltre, la semplice creazione di un’opzione per modificare la propria politica di mempool locale (che è disattivata per impostazione predefinita) non è in alcun modo dettare il cambiamento a nessuno, è un’opzione data agli utenti di fare una scelta da soli. Alla fine della giornata, quando si tratta di quali transazioni verranno effettivamente incluse nel blocco successivo, gli unici mempool che contano sono quelli dei minatori. I mempool dei nodi dei singoli utenti non sono altro che una catena a margherita di storage di memoria con l’obiettivo finale di propagare tutte quelle transazioni non confermate ai miner in modo che possano essere eventualmente incluse in un blocco.
La policy di Mempool viene utilizzata come una sorta di meccanismo di sicurezza morbida per prevenire attacchi denial-of-service ai nodi e proteggere gli utenti dal spararsi ai piedi con transazioni e script complicati. Molti tipi di transazioni sono validi per consenso, possono essere inclusi in un blocco, ma non verranno inoltrati dalla politica di mempool predefinita dei nodi. Questo, tuttavia, non fa nulla per impedire a un determinato utente di inoltrare una transazione che verrebbe ignorata dai nodi della rete direttamente a un minatore.
Questo è il nocciolo della questione. Tutto ciò che serve è che i minatori configurino un’API per inviare loro direttamente le transazioni, cosa che molti già hanno, e le restrizioni delle politiche di mempool sulla rete non contano. Puoi semplicemente dare una transazione direttamente ai minatori e ignorare ogni regola su quando qualcosa può essere sostituito nel mempool di altri nodi. Pensa agli incentivi di questo: se ci sono soldi da guadagnare estraendo una certa classe di transazioni, ma i mempool sulla rete non li trasmetteranno, cosa faresti come minatore? Accettali direttamente. Più il sussidio si riduce e le commissioni di transazione crescono come percentuale delle entrate dei minatori, più diventa inevitabile che i minatori accetteranno direttamente sostituzioni che pagano commissioni più elevate se i nodi sulla rete non le trasmetteranno indirettamente. È inevitabile.
Questa modifica non altera la politica di mempool predefinita per Bitcoin Core, presenta semplicemente un’opzione per un singolo operatore di nodo di modificare la propria politica di mempool locale se lo desidera.
E potrei aggiungere, questa è una scelta che è sempre stata disponibile se gli utenti hanno scelto di modificare il proprio client. Tutto ciò che fa è rendere più semplice una scelta che è sempre stata disponibile per gli utenti. Gli incentivi portano inevitabilmente allo stato in cui tutte le transazioni saranno sostituibili se i minatori agiranno in modo economicamente razionale: è inevitabile. L’unica questione è se il software dovrebbe riflettere questi incentivi, in un modo che consente ai singoli utenti di decidere da soli quale politica utilizzare per il proprio mempool, o se le persone dovrebbero semplicemente sedersi e lasciare che la propagazione delle transazioni si accentri attorno all’invio diretto ai miner loro stessi?
Il risultato finale è lo stesso, ma aspettare che i minatori gravitino sull’invio diretto delle transazioni avrà conseguenze molto negative. Avrebbe implicazioni sulla privacy per le persone che trasmettono transazioni sulla rete e potrebbe avere conseguenze molto negative per la capacità degli utenti di decidere quale tariffa pagare per una transazione. Se grandi porzioni di transazioni in sospeso non vengono più trasmesse pubblicamente attraverso la rete, gli utenti avranno una visione incompleta di chi stanno facendo offerte per l’inclusione in un blocco. I minatori potrebbero persino mentire sulla distribuzione delle commissioni per incentivare gli utenti a pagare più del dovuto.
L’unico vero svantaggio di rendere disponibile questa opzione è che l’RBF completo potrebbe non funzionare in modo coerente se solo una piccola parte della rete, inclusi i miner, scegliesse di abilitare l’RBF completo. Tuttavia, questo fondamentalmente non è diverso in termini di transizione rispetto all’aggiornamento a SegWit. Durante quel periodo di transizione, i nodi non aggiornati non trasmettevano le transazioni SegWit perché non erano in grado di convalidarle, quindi durante quel periodo la stessa dinamica di propagazione era incoerente fino a quando un numero sufficiente di utenti non veniva aggiornato. Ma alla fine, ciò non ha cambiato il fatto che l’aggiornamento era una decisione che spettava ai singoli utenti.
In definitiva, combattere l’RBF completo significa solo negare la realtà degli incentivi sulla rete. Niente viene imposto a nessuno, un’opzione di configurazione offre semplicemente ai singoli utenti una scelta da fare da soli. Trovo strano che allo stesso tempo così tante persone ignorino la realtà degli incentivi per sostenere che un mezzo non sicuro per ricevere i pagamenti può essere mantenuto al sicuro a dispetto degli incentivi, proprio come le persone sostengono che agli utenti di software non dovrebbe essere consentita la scelta su come per configurare il proprio software.
Il mio nodo, le mie regole, giusto?
Questo è un post degli ospiti di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.
