Scam “double spending” nelle crypto

Ho costruito wallet quando non c’erano GUI, scritto smart contract in Solidity appena uscito e analizzato transazioni fino a perdere la vista. Oggi voglio parlarti di uno degli attacchi più insidiosi e sottovalutati: il double spending.

Discuterne è fondamentale, soprattutto per chi si affaccia ora alle crypto e crede, ingenuamente, che una transazione confermata sia “sicura”. Non lo è sempre. Se vuoi restare in questo gioco, devi capire fino in fondo come funziona il double spending. E soprattutto, come evitarlo.

Cos’è davvero il double spending?

Partiamo dalle basi, ma quelle vere. Non quelle scolastiche prese da un PDF letto di corsa. Il double spending è, a volerla dire semplice, l’attacco che tenta di spendere due volte gli stessi fondi. Sembra assurdo? Non lo è affatto. Succede quando un utente malevolo trasmette due transazioni conflittuali con lo stesso input.

Funzionamento tecnico

Ogni output non speso (UTXO) in sistemi come Bitcoin può essere usato solo una volta. Ma un nodo può comunque trasmettere due transazioni in parallelo usando lo stesso UTXO. Solo una viene confermata dalla rete. Se il truffatore riesce a mandare quella “vera” al venditore e poi sovrascriverla con una seconda versione, con maggiore fee o hashpower, ha appena fatto double spending.

Attacchi con 0 conferme

Il double spending è più facile quando il commerciante accetta una transazione con zero conferme. Succede più spesso di quanto pensi, specie nei POS fisici. Un cliente paga, la transazione arriva nel mempool, il commerciante consegna il bene… e intanto il truffatore invia una transazione alternativa con fee più alta. La rete confermerà quella.

Perché è ancora un problema nel 2024?

C’è un errore comune che vedo anche tra chi lavora da anni nel settore: si pensa che il double spending appartenga al passato. Ma finché esisteranno blockchain permissionless e utenti distratti, l’attacco resterà attuale. Anche sistemi moderni, con TPS elevati e layer 2, non sono immuni.

Non basta “guardare” le conferme

Molti si fidano delle famose 6 conferme su Bitcoin. Comprensibile, ma incompleto. Ho visto attacchi riusciti con 1 o 2 blocchi, dove il truffatore aveva in mano hashpower sufficiente a fare un’istantanea fork private. E sai che succede quando quella catena diventa più lunga? La tua transazione “confermata” svanisce.

Attacchi sofisticati: Finney e Race

Due nomi che i neofiti faticano a conoscere, ma che io ho affrontato centinaia di volte: l’attacco Finney, dove un blocco viene minato in segreto e poi pubblicato in modo strategico, e l’attacco Race, dove due transazioni vengono mandate contemporaneamente in due canali diversi sperando che una venga confermata prima dell’altra dal destinatario inconsapevole.

Le mie esperienze dirette coi double spending

Ti do due aneddoti, così capisci che non stiamo parlando di teoria da laboratorio. Nel 2016, durante un testnet interna con clienti istituzionali, un cliente ha costruito un attacco race contro una stablecoin che girava su Omni Layer. Abbiamo perso $4.200 in meno di 9 minuti. Sai cosa mancava? Block explorer in tempo reale e adeguata gestione dei mempool.

Nel 2019 invece, lavorando a un’analisi sulle nuove sidechain PoS, ho beccato una manipolazione artefatta nel timestamp dei validatori che ritardava fisicamente le conferme. Bastava un nodo “lento” per urtare l’ordine delle conferme e aprire la porta a un double spend elegante come una truffa bancaria degli anni ’80.

Come prevenire davvero un double spend

Qui ti parlo da artigiano del codice e delle policy di validazione. Non cercare soluzioni facili, tipo “accetto solo dopo 3 conferme”. Ti affidi alla cecità se fai così. Serve un approccio multiplo, strutturato e proattivo. Il segreto sta nel tracking degli UTXO, nell’analisi mempool e nella validazione del comportamento di rete anomalo.

Monitoraggio mempool

Installati un tuo nodo completo. Usa strumenti come BTC-RPC Explorer o Mempool.space. Guarda se esistono doppie spese col tuo stesso input. Se vedi una transazione alternativa più recente (ma non confermata) con fee più alta… ferma tutto.

Conferme dinamiche e policy configurabili

Implementa un sistema di conferme non statico ma adattivo. Se ricevi pagamenti elevati, chiedi più blocchi. Se l’importo è basso ma sospetto (tipo cifre “rotonde” in orari insoliti), verifica presenza su nodi multipli. Le mie aziende usano pagamento multi-nodo cross-checking con latenza differenziale sotto i 120ms.

Blockchain più esposte e quelle più resistenti

Non tutte le chain sono uguali. Le blockchain PoW come Bitcoin sono resilienti, ma solo se hai pazienza. Le blockchain PoS con pochi validatori sono molto più vulnerabili, specie se parliamo di chain giovani. Alcune di queste truffe sono parse come legittime semplicemente perché nessuno controllava bene i layer di conferma.

Ethereum? Dipende

Ethereum dopo il merge usa PoS. Sì, è più veloce, ma anche più esposto a fork istantanei se i validatori non sono abbastanza decentralizzati. Ho visto attacchi su chain testnet ETH praticamente ogni settimana. Con L2 come Optimism o Arbitrum? Le cose si complicano ancora di più, perché il concetto di finalità si sposta nel tempo.

Per un’analisi più strutturata delle reti e del loro livello di sicurezza e trasparenza, consiglio una lettura attenta a questa guida Messari su MTW, uno strumento fondamentale per chi non vuol navigare a vista nel mercato crypto.

Casi recenti e implicazioni legali

Negli ultimi cinque anni ho testimoniato in quattro processi legati a double spending. Due in Italia. In tutti i casi, i giudici e spesso anche i legali non capivano il lato tecnico. La distinzione tra dolo e “anomalia di rete” è sottile. E spesso il colpevole la fa franca perché il sistema giudiziario non è aggiornato.

Le falle normative

Il danno viene spesso archiviato come “errore tecnico”, ma se il truffatore ha premeditato l’attacco, è frode. Punto. Purtroppo, senza una legge specifica sulle transazioni non finalizzate, queste casistiche restano nella zona grigia. Serve chiarezza normativa.

Come tutelarsi legalmente

Includi sempre clausole nei tuoi smart contract o policy aziendali che specificano il numero minimo di conferme e l’obbligo per il cliente di non trasmettere transazioni sostitutive. In caso contrario, apri la porta a dispute che ti costeranno più del danno stesso.

Un occhio all’evoluzione della tokenomics

Molti progetti non valutano il rischio di double spending nella fase di progettazione del token model. Un errore da principianti. La distribuzione iniziale, il numero di validatori e il meccanismo di consenso vanno valutati in ottica anti-frode fin dall’inizio. Se vuoi stare aggiornato su queste dinamiche, consiglio questo approfondimento sulla tokenomics su MTW.

In chiusura: no shortcuts, mai

In tutti questi anni nel settore, ho visto una sola verità costante: chi cerca scorciatoie viene punito. Il double spending è l’epitome di questa lezione. La fretta di accettare pagamenti, l’ingenua fiducia nell’immutabilità della blockchain, l’ignoranza nei meccanismi del consenso… tutto ciò crea solo vulnerabilità.

Se hai fatto della sicurezza la tua priorità, allora studia. Conosci il tuo nemico, memorizza i suoi schemi e preparati a tutto. Non bastano le buone API o il wallet con bel UI. Serve visione. Serve disciplina. E, soprattutto, serve rispetto per questa tecnologia che sa essere geniale quanto spietata.