Cresce l’allarme per gli attacchi di replay mentre i sostenitori del BIP-110 definiscono Bitcoin “spamcoin”

La questione è rilevante perché Luke Dashjr e altri sostenitori del BIP-110 stanno discutendo di un hard fork che sostituirebbe l’algoritmo di mining SHA-256d della catena minoritaria con BLAKE2b. Una mossa del genere creerebbe in modo permanente un design completamente nuovo, ma le due reti continuerebbero a condividere la cronologia delle transazioni precedente alla scissione.

Che cos’è esattamente un attacco di replay?

Immaginiamo che qualcuno possieda 1 bitcoin prima di un hard fork. Quando la blockchain si divide, lo stesso output di transazione non speso (UTXO) esiste su entrambe le reti. In pratica, il proprietario controlla le monete corrispondenti su ciascuna catena con la stessa chiave privata.

I problemi iniziano se entrambe le reti riconoscono anche le stesse regole relative alle transazioni e alle firme. Supponiamo che il proprietario invii la moneta a un exchange sulla Catena A. Se quella transazione firmata è valida anche sulla Catena B, un’altra parte può copiarla e trasmetterla lì. La Catena B potrebbe accettare la transazione perché, dal punto di vista crittografico, nulla distingue l’autorizzazione da una destinata alla propria rete.

Questo è un replay. Nessuno ruba la chiave privata né viola la crittografia di Bitcoin. Il problema è più semplice: l’utente ha creato un’unica autorizzazione valida, ma due blockchain la riconoscono. E mentre la catena BIP-110 si trova all’altezza del blocco 961636, chi spende BTC sta trasferendo monete BIP-110, o comunque si chiameranno in futuro, contemporaneamente, senza nemmeno saperlo. “La stragrande maggioranza di questi [BIP-110 minority chain] blocchi si limita a riprodurre transazioni risalenti a giorni fa provenienti dalla catena principale”, ha scritto su X Mononaut, sviluppatore di Mempool.space. Il tema della protezione dal replay o degli attacchi di replay ha suscitato una discussione virale su X negli ultimi giorni.

La protezione dal replay erige un muro tra le catene

La protezione contro il replay impedisce tale incrocio distinguibili le transazioni sulle reti concorrenti. Un metodo consiste nel modificare l’hash della firma, comunemente chiamato sighash, in modo che una transazione firmata per una catena non soddisfi le regole di consenso dell’altra.

La protezione obbligatoria rende questa distinzione parte integrante del fork stesso. La protezione opt-in lascia le transazioni ordinarie potenzialmente compatibili con entrambe le catene e richiede agli utenti di utilizzare deliberatamente un meccanismo specifico per ciascuna catena quando desiderano separare le proprie monete.

Tale distinzione è diventata importante per il BIP-110. Il piano emergente non sembra fornire una protezione automatica e completa contro il replay bidirezionale. Al contrario, almeno secondo le discussioni su Discord, Bitcoin Knots sta implementando una nuova opzione di sighash in grado di creare una transazione valida sulla catena RDTS ma non valida su Bitcoin Core.

Dashjr afferma che la protezione è un problema dell’altra catena

Dashjr ha assunto una posizione insolita riguardo a quale rete debba assumersi la responsabilità. Interrogato il 18 agosto sulla protezione dal replay per l’hard fork proposto, ha affermato: «La protezione dal replay era responsabilità di Spamcoin, dato che si tratta dell’altcoin distribuito tramite airdrop».

Ha aggiunto che ci sarebbero modi per separare le transazioni, ma ha sostenuto che «le transazioni Bitcoin legittime devono rimanere valide su Bitcoin». Il suo ragionamento si basa sull’affermazione che la rete minoritaria BIP-110/RDTS sia Bitcoin, mentre la blockchain Bitcoin SHA-256d, prevalentemente dominante, sia la rete scissionista.

Dashjr ha ripetutamente utilizzato nomi dispregiativi per la catena dominante di Bitcoin, tra cui «Spamcoin» e «Bpedo», un riferimento che incorpora il termine «pedo». Ha definito quella rete come l’altcoin, continuando a descrivere il ramo BIP-110 come il Bitcoin legittimo.

I dati della rete raccontano una storia molto diversa

Tale caratterizzazione si scontra con l’attività osservabile sulla rete. La segnalazione dei miner BIP-110 ha raggiunto un picco di circa il 2,53% e, quando le sue regole di consenso sono entrate in vigore l’8 agosto, il suo ramo minoritario ha prodotto solo due blocchi immediati prima di arrestarsi. La catena dominante di Bitcoin ha continuato a funzionare mentre il divario si allargava di centinaia di blocchi. Alcuni altri blocchi BIP-110 sono stati estratti a un ritmo estremamente lento.

La rete maggioritaria ha mantenuto sostanzialmente tutto l’hashrate significativo di Bitcoin, la catena più lunga, il peso del lavoro, la liquidità e il riconoscimento economico. La proposta BIP-110 è stata successivamente contrassegnata come chiusa, mentre i sostenitori si sono orientati verso piani per una modifica del proof-of-work (PoW) BLAKE2b volta a rilanciare la rete minoritaria.

Inoltre, la comunità Bitcoin è frustrata dalle ripetute affermazioni di Dashjr e la protezione contro il replay in stile “opt-in” di cui si sta discutendo è oggetto di controversia. "Lol. Luke non lancerà mica la sua sh**coin con la protezione contro i replay, vero? Immagino che allora non verrà quotata sugli exchange", ha scritto mercoledì un utente di X. Un altro utente di X ha obiettato:

"Questo ha superato il limite tra assurdità e comportamento scorretto. Diffondere informazioni false come queste può causare un vero danno finanziario ai Bitcoiners."

La protezione ‘opt-in’ lascia la responsabilità agli utenti

Secondo l’approccio attualmente in discussione sul canale Discord di Bitcoin Knots, le transazioni ordinarie potrebbero rimanere soggette a replay perché RDTS intende mantenere la compatibilità con i tipi di sighash esistenti di Bitcoin Core. Gli utenti che desiderano una protezione specifica per RDTS dovrebbero utilizzare il nuovo sighash, il che richiede un software di portafoglio compatibile o un firmware con firma hardware.

Gli utenti possono anche provare a suddividere manualmente le proprie monete. Una transazione Bitcoin contenente dati rifiutati da RDTS potrebbe creare un output esistente solo sulla catena dominante. Al contrario, il sighash specifico per RDTS proposto potrebbe produrre una transazione accettata da RDTS, ma rifiutata da Bitcoin Core.

Il risultato assomiglia molto di più a una protezione contro il replay di tipo «opt-in» che al firewall automatico che gli utenti si aspettano da un hard fork controverso. Ciò lascia ai portafogli, agli exchange e ai possessori la responsabilità di sapere esattamente quali transazioni possano propagarsi tra le catene. La decisione è strana, specialmente per una nuova catena e un asset crittografico senza alcun supporto da parte degli exchange. È improbabile che i fornitori di infrastrutture, in particolare gli exchange di criptovalute, prendano in considerazione una catena che preferisce una protezione “opt-in” a una barriera universale contro il replay. Se il fork BLAKE2b procederà intorno al 1° settembre, la protezione contro il replay sarà quindi ben più di un oscuro dettaglio tecnico. Diventerà una prova pratica per verificare se gli utenti siano in grado di separare in modo sicuro gli asset ereditati dalla stessa storia di Bitcoin, anche se Dashjr continua ad affermare, in modo decisamente più ambizioso, che la rete che gestisce praticamente tutto l’hashrate, la liquidità e l’attività economica di Bitcoin sia in qualche modo l’altcoin.