Se mandi una foto a un amico, la foto resta anche a te. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il denaro che esiste solo come dato ha lo stesso difetto: senza una regola in più, potresti inviare la stessa moneta digitale a due persone e tenerla pure per te. Questa è la doppia spesa, in inglese double spending, e ogni forma di denaro elettronico ha dovuto risolverla. Bitcoin la risolve con un registro pubblico che mette in fila tutti i pagamenti. La difesa è solida, con due punti deboli: i minuti prima che un pagamento entri nel registro e i rari momenti in cui la rete tiene due versioni dello stesso registro.
Uno di quei momenti arrivò nella notte dell’11 marzo 2013. Un aggiornamento del software spaccò per errore la rete Bitcoin e per qualche ora due versioni del registro crebbero una accanto all’altra. Un utente, per sua stessa ammissione sul forum Bitcointalk, pagò 211,9 bitcoin, circa 10.000 dollari di allora, al servizio di pagamento OKPay su una versione, mentre una seconda transazione che rimandava gli stessi fondi a lui finiva nell’altra. Quando i miner riportarono la rete a una sola versione, quella vincente non conteneva il pagamento a OKPay. Era sparito.
L’analisi tecnica dei due fronti, la BIP 50 degli sviluppatori di Bitcoin, conferma «at least one large double spend» (almeno una doppia spesa di grande importo) e spiega che a farla fu qualcuno che voleva provare se fosse possibile, e che non era «intended to be malicious», cioè non aveva intento malevolo. È la doppia spesa di un pagamento confermato più nota sulla rete Bitcoin vera e propria. E mostra la regola su cui gira tutta questa lezione: quando due pagamenti usano gli stessi fondi ne sopravvive uno solo, e tutto dipende da quale dei due la rete decide di tenere.
Cos’è la doppia spesa (double spending)?
La doppia spesa è il rischio che la stessa unità di denaro digitale venga spesa più di una volta, perché un file o un messaggio si copia a costo zero. Qualunque sistema di contante elettronico deve garantire che, quando due pagamenti usano gli stessi fondi, ne conti uno solo e che tutti siano d’accordo su quale.
Perché una moneta digitale si copia e una banconota no
Una banconota è un oggetto fisico. Quando la consegni al negoziante non ce l’hai più, e nessuno ha bisogno di consultare un registro per saperlo. Una moneta digitale è una sequenza di byte, e i byte si copiano quante volte si vuole senza spendere nulla. Se mandi un «file moneta» per email, ce l’hai ancora sul tuo computer, pronto per essere inviato di nuovo.
Le firme digitali non risolvono il problema. Una firma dimostra che il proprietario ha approvato un pagamento; non dice nulla sul fatto che lo stesso proprietario abbia già approvato un altro pagamento della stessa moneta a un’altra persona. Due transazioni perfettamente valide e perfettamente firmate possono spendere gli stessi fondi. Chi riceve l’una non può accorgersi, guardandola da sola, che esiste anche l’altra.
La doppia spesa è una questione di ordine, non di falsificazione
Il punto, quindi, non è impedire a qualcuno di scrivere un secondo pagamento. Chiunque può scriverlo. Il compito vero è decidere quale di due pagamenti in conflitto sia arrivato prima e far accettare quella decisione a tutti. Satoshi Nakamoto lo dice con chiarezza nella sezione 2 del white paper di Bitcoin (in inglese): «the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend.» In italiano: conta la transazione più antica, e dei tentativi successivi non ci si preoccupa.
La stessa sezione indica la parte difficile: «The only way to confirm the absence of a transaction is to be aware of all transactions.» Per sapere che una moneta non è già stata spesa serve un registro completo e condiviso di tutti i pagamenti e del loro ordine. Per decenni l’unico modo noto per costruirlo è stato affidarlo a un’unica parte di fiducia.
Prima di Bitcoin, un contabile centrale risolveva ogni disputa
Banche e circuiti di carte: un registro, un impiegato
Il tuo conto in banca non è un mucchio di monete. È una riga in un database controllato dalla banca. Quando paghi con la carta o con un bonifico, la banca o il circuito scrive l’addebito, controlla il saldo e rifiuta il secondo pagamento se i soldi sono finiti. In questo schema la doppia spesa è impossibile perché un solo impiegato vede tutte le richieste e le mette in ordine. Il prezzo da pagare è dipendere da quell’impiegato: può bloccare, stornare o rifiutare un pagamento, e i suoi registri sono l’unica verità.
La zecca di Chaum: controlli in linea, cheater scoperti dopo
I primi tentativi seri di contante digitale tenevano un contabile. Nell’eCash di David Chaum una banca, o «zecca», emetteva le monete e controllava ciascuna al momento della spesa, rifiutando quelle già viste. La nostra lezione sul denaro digitale prima di Bitcoin racconta questa storia, insieme a Hashcash, b-money e bit gold. Quello che conta qui è che cosa accadeva quando la zecca era offline: il sistema non poteva fermare la doppia spesa, ma solo smascherare il colpevole in un secondo momento. Hal Finney, spiegando nel 1993 lo schema offline di Chaum, ne riassunse la promessa così: «Anonymity as long as you don’t cheat, and double-spenders get caught» (anonimato finché non imbrogli, e chi spende due volte viene scoperto), nel suo testo «Detecting Double-Spending».
Il paper di Nakamoto descrive quel modello e il suo limite in una frase: una risposta comune è «to introduce a trusted central authority, or mint, that checks every transaction for double spending», cioè introdurre un’autorità centrale fidata, una zecca, che controlla ogni transazione. Tutto dipende allora dall’azienda che gestisce la zecca, con ogni pagamento che passa da lei, «just like a bank». L’obiettivo di Bitcoin era tenere la protezione e togliere la zecca.
Come Bitcoin risolve la doppia spesa senza un’autorità centrale
L’abstract del white paper dichiara l’ambizione in una riga: «We propose a solution to the double-spending problem using a peer-to-peer network.» La soluzione ha più parti, ciascuna semplice. La nostra guida al white paper di Bitcoin spiegato riassume l’intero documento; questa lezione segue solo il filo della doppia spesa.
Ogni pagamento viene annunciato a tutti
Invece di mandare il pagamento a un solo impiegato, un wallet Bitcoin lo trasmette a tutta la rete dei computer che eseguono il software, i cosiddetti nodi. Ogni nodo lo passa ad altri. La sezione 2 del white paper dice che le transazioni devono essere «publicly announced», annunciate pubblicamente, perché i partecipanti possano accordarsi su un’unica storia dell’ordine in cui sono state ricevute. Una volta che un pagamento è pubblico, lo è anche un secondo pagamento delle stesse monete, e il conflitto diventa visibile.
I blocchi mettono i pagamenti in un ordine pubblico
Vedere il conflitto non basta: i nodi possono ricevere i due pagamenti in ordine diverso, a seconda di dove si trovano nella rete. La sezione 3 del paper comincia così: «The solution we propose begins with a timestamp server.» Bitcoin raggruppa i pagamenti in blocchi, e ogni blocco contiene l’impronta del precedente, così i blocchi formano una catena nel tempo. Un pagamento incluso in un blocco ha una posizione in quella catena; un pagamento in conflitto può arrivare solo dopo, e chi arriva dopo perde.
Ecco che cosa significa «conferma»: un pagamento riceve la prima conferma quando viene incluso in un blocco, e una in più ogni volta che si aggiunge un nuovo blocco sopra. Più è in profondità, più è difficile spostarlo.
I nodi rifiutano ogni moneta già spesa
Bitcoin non tiene traccia dei saldi, ma delle uscite non spese: ogni pagamento consuma per intero uscite precedenti e ne crea di nuove, come spiegato nella lezione precedente sui modelli UTXO e account. Ogni nodo conserva l’elenco delle uscite ancora non spese. Quando una transazione prova a spendere un’uscita che non è più in quell’elenco, il nodo la rifiuta, e un blocco che la contiene è non valido per ogni nodo onesto. La doppia spesa, dunque, non è un trucco contabile: è una gara per stabilire quale di due transazioni dall’aspetto valido entra per prima nella storia condivisa.
Due blocchi insieme: vince la catena con più lavoro
A volte due miner trovano un blocco quasi nello stesso momento, e per un breve periodo la rete ha due versioni dell’ultima pagina. La nostra lezione su come funziona una blockchain mostra come si risolve: i miner continuano a costruire, un ramo prende vantaggio e tutti i nodi passano a quello. La regola del paper è che «Nodes always consider the longest chain to be the correct one and will keep working on extending it.»
«Più lunga» va intesa con attenzione. Nella sezione 4 il paper dice che la decisione di maggioranza spetta alla catena «which has the greatest proof-of-work effort invested in it», quella con il maggior lavoro di proof of work investito. È la catena con più lavoro accumulato, non con più blocchi, ed è ciò che confronta davvero il software Bitcoin Core. Produrre quel lavoro costa elettricità e hardware veri, ed è per questo che riscrivere la storia di una blockchain ha un prezzo.
Quando i nodi passano da un ramo all’altro, i blocchi del ramo abbandonato escono dalla catena. Gli ingegneri lo chiamano riorganizzazione, o reorg. Ogni pagamento che stava solo nel ramo abbandonato perde le sue conferme, e se nel ramo vincente c’è un pagamento in conflitto, il primo non potrà più essere incluso. Una reorg è il momento in cui una doppia spesa diventa reale.
Che cosa può e non può fare un attaccante
La sezione 11 del paper è precisa sui limiti di chi imbroglia, anche con molta potenza di calcolo. Dice che «An attacker can only try to change one of his own transactions to take back money he recently spent.» L’attaccante può solo cercare di cambiare una sua transazione per riprendersi denaro speso da poco. Non può creare monete dal nulla né spendere monete che non sono mai state sue, perché i nodi onesti rifiutano le transazioni non valide qualunque sia la catena. Il pericolo è circoscritto: un pagamento recente dell’attaccante, annullato dopo che la vittima ha consegnato la merce o il denaro.
Cinque modi di spendere due volte
La pagina del wiki di Bitcoin sulle transazioni irreversibili (in inglese) elenca gli attacchi classici di doppia spesa. Si distinguono per il momento in cui colpiscono e per la potenza di cui l’attaccante ha bisogno. Alcuni richiedono solo un wallet. Il più forte richiede hashrate, la potenza di calcolo spesa nel mining, che è la risorsa a decidere quale versione del registro vince.
| Attacco | Quando funziona | Chi può farlo | Difesa principale |
|---|---|---|---|
| Race attack | Pagamento accettato con zero conferme | Chiunque abbia un wallet | Aspettare almeno una conferma |
| Sostituzione con replace-by-fee | Pagamento accettato con zero conferme | Chiunque abbia un wallet | Non considerare mai pagato un pagamento non confermato |
| Finney attack | Pagamento accettato con zero conferme | Un miner che trova blocchi | Aspettare le conferme |
| Vector76 | Pagamento accettato dopo una conferma | Un miner, ben posizionato nella rete | Aspettare più conferme |
| Attacco di maggioranza (51%) | Anche dopo molte conferme | Chi controlla la maggior parte dell’hashrate | Più conferme alzano il costo; le catene piccole ne richiedono molte di più |
Race attack: due pagamenti in conflitto insieme
Il tentativo più semplice non richiede attrezzature speciali. Chi imbroglia manda un pagamento a un commerciante e, quasi nello stesso istante, una seconda transazione che spende le stesse monete verso un indirizzo proprio, diffusa al maggior numero possibile di nodi e miner. Se la seconda raggiunge i miner per prima, finisce in un blocco e il pagamento al commerciante cade. Il wiki di Bitcoin dice che i commercianti possono ridurre il rischio, per esempio collegandosi a nodi ben connessi, ma «the risk cannot be eliminated», il rischio non si elimina. Funziona solo contro chi accetta un pagamento prima che sia confermato.
Replace-by-fee: quando il mittente può cambiare il pagamento
Il replace-by-fee (RBF) è una funzione normale, non un attacco: permette a chi invia di sostituire una transazione non confermata con una nuova versione che paga una commissione più alta, di solito per sbloccare un pagamento fermo. La nostra guida su come funzionano le transazioni crypto mostra come si fa. Il problema per chi riceve è che la nuova versione può anche spedire il denaro altrove.
In origine la sostituzione era facoltativa. Con la BIP 125, assegnata a dicembre 2015, una transazione segnalava di poter essere sostituita, e la proposta notava che chi riceve può scegliere di non considerare pagato un pagamento del genere finché non è confermato. Quella distinzione è venuta meno. Bitcoin Core 28.0, uscito il 2 ottobre 2024, ha reso il full replace-by-fee il comportamento predefinito, e Bitcoin Core 29.0, uscito il 14 aprile 2025, ha eliminato l’opzione per disattivarlo. Su Bitcoin Core, il software usato dalla maggior parte dei nodi, qualunque pagamento non confermato può essere sostituito da uno in conflitto che paga di più, abbia o no segnalato la sostituibilità. Si tratta di una politica di inoltro, non di una regola di consenso: i miner possono usare altro software, ma un commerciante non può contare su questo.
Finney attack: un miner nasconde un blocco
Il 13 febbraio 2011 Hal Finney descrisse sul forum di Bitcoin un imbroglio alla portata di un miner. Il suo messaggio si apre con «Suppose the attacker is generating blocks occasionally.» Il miner mette un trasferimento tra due propri indirizzi in un blocco che ha trovato ma non ancora pubblicato. Poi paga un commerciante con le stesse monete. Se il commerciante consegna la merce senza aspettare, il miner pubblica il suo blocco, che spende già quelle monete, e il pagamento al commerciante diventa non valido. Lo scenario porta oggi il nome di Finney. Richiede potenza di mining e un po’ di fortuna con i tempi e, come il race attack, sconfigge solo chi accetta zero conferme.
Vector76: una conferma non sempre basta
L’attacco Vector76 unisce i due precedenti. L’attaccante mina un blocco che contiene un deposito, lo manda solo alla vittima, tipicamente un exchange, e lascia che il resto della rete costruisca su un blocco con una transazione in conflitto. La vittima vede per un attimo una conferma, accredita il deposito e consente all’attaccante di prelevare; quando il suo nodo si riallinea al resto della rete, il deposito svanisce. L’attaccante rinuncia a una ricompensa di blocco per farlo, quindi ha senso solo contro un prelievo grande e veloce. Una conferma è molto meglio di nessuna, ma non è una garanzia.
Attacco di maggioranza: riscrivere la storia recente
La versione seria è quella modellata nel white paper. Un attaccante mina in segreto un ramo in cui il suo pagamento alla vittima non è mai avvenuto, aspetta che la vittima consegni, poi pubblica il suo ramo. Se ha più lavoro accumulato di quello pubblico, ogni nodo passa al suo ramo e il pagamento della vittima scompare. Chi controlla più della metà dell’hashrate della rete può vincere questa gara alla lunga, ed è per questo che si parla di attacco del 51%. Sotto la metà, la probabilità di successo dell’attaccante cala in fretta a ogni conferma che la vittima aspetta.
Le cifre di Nakamoto, sempre nella sezione 11, indicano la probabilità che l’attaccante riesca a recuperare, in funzione della sua quota di hashrate e del numero di conferme che la vittima aspetta:
| Quota di hashrate dell’attaccante | Conferme attese | Probabilità che l’attaccante recuperi (white paper) |
|---|---|---|
| 10% | 1 | 0,2045873 |
| 10% | 5 | 0,0009137 |
| 10% | 6 | 0,0002428 |
| 30% | 5 | 0,1773523 |
| 30% | 10 | 0,0416605 |
| 30% | 24 | sotto 0,001 (seconda tabella del paper) |
| 30% | 50 | 0,0000006 |
In parole semplici: con il 10% dell’hashrate, un attaccante che si trova davanti sei conferme riesce circa 2,4 volte su 10.000 tentativi, nel modello del paper. Con il 30%, cinque conferme gli lasciano ancora quasi il 18% di probabilità, e alla vittima servono 24 conferme per portare il rischio sotto lo 0,1%. Analisi successive con ipotesi diverse danno valori più alti, quindi la tabella va letta come il modello semplificato del paper e non come una previsione precisa. Sopra il 50%, nessun numero di conferme protegge la vittima; il wiki dice «No amount of confirmations can prevent this attack», anche se aspettare alza il costo per l’attaccante. Una futura lezione di Coindaro sugli attacchi del 51% entrerà nei dettagli della loro economia.
Doppie spese reali, dal 2013 al 2020
Le doppie spese ci sono state, e i fatti mostrano uno schema chiaro: una su Bitcoin, durante una divisione accidentale, le altre su catene proof of work più piccole il cui hashrate si poteva noleggiare. La nostra guida su se una blockchain può essere hackerata racconta nel dettaglio i casi di Bitcoin Gold ed Ethereum Classic; qui c’è la versione breve.
| Data | Catena | Che cosa è successo | Importo riportato (all’epoca) | Fonte |
|---|---|---|---|---|
| 11-12 marzo 2013 | Bitcoin | Divisione accidentale tra nodi 0.8 e nodi più vecchi; un pagamento di 211,9 BTC a OKPay annullato | circa 10.000 dollari, secondo il resoconto dell’utente | BIP 50; il thread dell’utente sul forum |
| Dal 18 maggio 2018 | Bitcoin Gold | Un attaccante con la maggioranza dell’hashrate ha fatto doppie spese sui depositi presso gli exchange | oltre 388.000 BTG transitati dall’indirizzo dell’attaccante; più di 18 milioni di dollari, stima di BleepingComputer | BleepingComputer, 24 maggio 2018 |
| Dal 5 gennaio 2019 | Ethereum Classic | Riorganizzazioni profonde con doppie spese individuate da Coinbase | 219.500 ETC in 13 doppie spese, circa 1,1 milioni di dollari | Infosecurity Magazine, 8 gennaio 2019 |
| Agosto 2020 | Ethereum Classic | Tre riorganizzazioni in un mese, di 3.693, circa 4.000 e più di 7.000 blocchi | non indicato nella fonte | The Block, 31 agosto 2020 |
Marzo 2013 non fu un attacco. Secondo la BIP 50, un blocco accettato dalla versione 0.8 fu respinto da alcuni nodi più vecchi, il lato 0.8 aveva circa il 60% della potenza di calcolo, e due grandi pool tornarono alla versione vecchia per chiudere la divisione. La doppia spesa funzionò anche se entrambi i lati avevano visto le transazioni nello stesso ordine, molto probabilmente perché le memory pool furono svuotate al riavvio dei nodi dei pool. Il resoconto dell’utente sul pagamento è in un thread del forum del 12 marzo 2013, a cui rimanda la stessa analisi post-mortem. Secondo quel racconto, il pagamento a OKPay era un deposito sul suo conto presso l’exchange BTC-e, e le due transazioni in conflitto furono minate alla stessa altezza, il blocco 225.446, una su ciascun ramo.
Bitcoin Gold, un fork di Bitcoin del 2017, fu colpita da un attaccante che controllava più della metà della sua potenza di mining. Secondo BleepingComputer, gli attacchi cominciarono il 18 maggio 2018, l’attaccante depositava monete presso gli exchange mentre mandava le stesse monete al proprio wallet, e dal suo indirizzo passarono più di 388.000 BTG, cosa che secondo il sito faceva pensare a un guadagno di oltre 18 milioni di dollari. Nel mirino c’erano gli exchange e non i singoli possessori: nessun utente aveva perso denaro, scriveva l’articolo.
Ethereum Classic, la catena che ha mantenuto la storia originale di Ethereum dopo il 2016, fu attaccata nel gennaio 2019. Coinbase rilevò il 5 gennaio una riorganizzazione profonda con una doppia spesa, poi altre 12 doppie spese, per un totale di 219.500 ETC, circa 1,1 milioni di dollari di allora, come riportato da Infosecurity Magazine. Nell’agosto 2020 la catena subì tre riorganizzazioni in un mese, l’ultima profonda più di 7.000 blocchi, circa due giorni di mining secondo l’operatore di pool Bitfly, stando a The Block.
La lezione di questi casi riguarda la dimensione. Riscrivere la catena di Bitcoin significherebbe superare l’hashrate della più grande rete proof of work. Su una catena il cui intero hashrate si può noleggiare per qualche ora, lo stesso attacco può costare meno delle monete rubate. Dopo l’attacco a Bitcoin Gold, gli exchange alzarono il numero di conferme richieste per i depositi, ha riportato BleepingComputer.
Perché sei conferme, e perché una basta per un caffè
Sei conferme, circa un’ora in media, sono diventate il margine di sicurezza abituale di Bitcoin. La lezione sul mempool e le commissioni di transazione spiega da dove viene la convenzione e come un pagamento passa dalla trasmissione al blocco. La tabella del white paper mostra perché è sensata: contro un attaccante con il 10% dell’hashrate, sei blocchi portano il rischio allo 0,024% nel modello del paper.
Sei è una convenzione, non una regola del protocollo. Ogni ricevente sceglie la propria soglia, e il numero giusto dipende da due cose: l’importo in gioco e l’hashrate della catena. Kraken, per esempio, accredita i depositi in Bitcoin dopo tre conferme, secondo la sua pagina di aiuto sui tempi di elaborazione dei depositi aggiornata il 22 ottobre 2026. Chi vende un’auto potrebbe aspettarne più di sei. Un bar che vende un caffè da 4 dollari può accettare il rischio di zero conferme, perché la perdita è piccola e l’imbroglione deve presentarsi al bancone.
Sulle catene proof of work più piccole lo stesso numero di blocchi offre molta meno sicurezza, perché produrli costa molto meno. Per questo un exchange può chiedere molte più conferme su una di queste catene che su Bitcoin.
Pagamenti a zero conferme: il vero rischio del commerciante
Finché non è confermato, un pagamento è una promessa annunciata, non un pagamento regolato. Tra il momento in cui il wallet mostra «ricevuto» e il primo blocco, chi invia può ancora tentare un race attack o, con il software dei nodi predefinito oggi, semplicemente trasmettere una sostituzione con una commissione più alta. Alle 09:50 UTC del 7 novembre 2026 mempool.space consigliava 2 satoshi per byte virtuale per la conferma più rapida, quindi una sostituzione potrebbe costare pochissimo a chi imbroglia.
I ricercatori diedero l’allarme presto. In un articolo del 2012, «Two Bitcoins at the Price of One?», Ghassan Karame, Elli Androulaki e Srdjan Čapkun partirono da un fast food che accettava bitcoin e mostrarono che le doppie spese contro pagamenti rapidi di quel tipo si potevano organizzare a basso costo con il software Bitcoin di allora.
Per un commerciante le regole pratiche sono poche:
- Considera un pagamento con zero conferme come non ancora ricevuto, a meno che l’importo non sia uno che sei pronto a perdere.
- Spedisci la merce o rilascia i fondi solo dopo il numero di conferme che hai scelto per quell’importo.
- Chiedi più conferme su una catena con poco hashrate che su Bitcoin.
- Per i pagamenti piccoli e istantanei usa un sistema pensato per questo, come una rete di canali di pagamento quale Lightning, invece di transazioni on-chain non confermate.
Ethereum e le altre catene ad account: ci pensa il nonce
Ethereum non usa uscite non spese. Tiene un saldo per ogni account, e ogni transazione porta un nonce, che la pagina di ethereum.org sulle transazioni descrive come «a sequentially incrementing counter which indicates the transaction number from the account», un contatore che cresce in sequenza e indica il numero della transazione dell’account. La prima transazione di un account usa il nonce 0, la successiva il nonce 1, e così via.
Il nonce svolge il ruolo che su Bitcoin ha l’«uscita già spesa». Due transazioni dello stesso account con lo stesso nonce sono in conflitto, e solo una può essere inclusa nella catena. La lezione sui modelli UTXO e account mostra l’altra faccia di questa regola, il nonce bloccato che ferma tutte le transazioni successive.
La logica dei pagamenti a zero conferme è la stessa di Bitcoin. Una transazione Ethereum in attesa può essere sostituita da un’altra con lo stesso nonce e una commissione più alta; le regole predefinite di Geth, un client Ethereum molto diffuso, chiedono una commissione di almeno il 10% più alta. Un pagamento ancora in attesa non è un pagamento.
Ethereum ha anche chiuso una porta che si era aperta con la divisione della catena nel 2016. Con l’EIP-155, una transazione firma l’identificativo della catena a cui è destinata, quindi non può essere copiata e riprodotta su un’altra catena che ne condivide la storia. Da quando è passata al proof of stake, Ethereum segna inoltre i blocchi come definitivi dopo un certo intervallo, tema di una lezione successiva su finalità e riorganizzazioni.
Solana: un blockhash recente che scade
Solana segue un’altra strada. Ogni transazione deve includere un blockhash recente, un riferimento a un blocco recente, e i validatori la accettano solo per un tempo limitato: l’SDK di Solana fissa l’età massima a 150 blockhash recenti, un minuto o meno alla velocità di Solana. Una transazione troppo vecchia viene rifiutata, quindi un pagamento firmato non può restare in giro per giorni in attesa di essere riprodotto. In quella finestra i validatori tengono anche traccia delle firme già elaborate e rifiutano la stessa transazione una seconda volta. Le spese in conflitto dallo stesso account vengono semplicemente ordinate dal validatore che produce il blocco.
Proof of stake: il «double signing» è un altro tipo di doppio
Sulle catene proof of stake la parola «doppio» compare con un altro significato. I validatori, che bloccano monete per partecipare, vengono puniti con lo slashing se firmano due versioni in conflitto della storia. La pagina di ethereum.org su ricompense e penalità elenca tre infrazioni: proporre e firmare due blocchi diversi per lo stesso slot, attestare un blocco che ne «circonda» un altro e il doppio voto, cioè attestare due candidati per lo stesso blocco.
Non è un utente che paga due volte. È un validatore che prova a sostenere due storie, esattamente ciò che servirebbe a una doppia spesa profonda. Lo slashing brucia parte della posta del validatore e lo espelle, quindi il tentativo è costoso e riconducibile a chi l’ha fatto. Un utente che manda due pagamenti in conflitto non subisce slashing: un pagamento semplicemente fallisce.
Nessuno storno in crypto: il confronto con carte e banche
Il rovescio del disegno di Bitcoin è che un pagamento confermato non ha un impiegato che possa annullarlo. Il white paper lo presenta come un vantaggio per chi vende: «Transactions that are computationally impractical to reverse would protect sellers from fraud.» Per chi ha pagato un truffatore significa che i soldi sono persi. La guida per i consumatori sulle truffe crypto della Federal Trade Commission statunitense lo dice senza giri di parole: «Cryptocurrency payments typically are not reversible.»
Il confronto con le carte e i bonifici è questo: un pagamento bancario o con carta è un credito su un registro tenuto da istituzioni che la legge può obbligare a stornare una scrittura; un trasferimento crypto confermato non ha una controparte del genere. Come esempio di ciò che esiste fuori dalle crypto, ecco le tutele di altri due paesi, ricavate dalle norme originali.
Negli Stati Uniti, secondo la Regulation E, la norma del CFPB sui trasferimenti elettronici, la responsabilità del consumatore per i trasferimenti non autorizzati è limitata a 50 dollari se la banca viene avvisata entro due giorni lavorativi da quando il consumatore ha saputo della perdita o del furto della carta, e a 500 dollari dopo, con 60 giorni dall’estratto conto per segnalare i trasferimenti non autorizzati. Con la Regulation Z, la responsabilità di chi ha una carta di credito per l’uso non autorizzato è limitata a 50 dollari, e un errore di fatturazione segnalato entro 60 giorni dall’estratto conto deve essere risolto entro due cicli di fatturazione e comunque non oltre 90 giorni.
Nel Regno Unito, le Payment Services Regulations 2017 impongono al prestatore di servizi di pagamento di rimborsare un pagamento non autorizzato entro la fine del giorno lavorativo successivo a quello in cui ne viene a conoscenza, salvo fondati sospetti di frode. La sezione 75 del Consumer Credit Act 1974 rende l’emittente della carta responsabile in solido con il venditore per acquisti singoli sopra le 100 sterline e fino a 30.000 sterline. Dal 7 ottobre 2024, perfino le vittime di truffe con pagamento autorizzato, cioè chi ha mandato il denaro a un truffatore di sua mano con Faster Payments o CHAPS, possono essere rimborsate fino a 85.000 sterline. Il limite per i Faster Payments l’ha fissato il Payment Systems Regulator e la Bank of England, che gestisce CHAPS, ha scelto lo stesso.
Niente di simile esiste su una blockchain pubblica. Un exchange può rimborsare un cliente di tasca propria, e un destinatario può scegliere di restituire le monete, ma il protocollo non ha un pulsante per contestare. La FTC lo dice così: di solito si riesce a riavere i soldi solo se la persona pagata li rimanda indietro. La nostra guida su come evitare le truffe crypto raccoglie le abitudini che contano di più quando non c’è nessuno storno.
Che cosa ricordare, da utente o da commerciante
Un registro pubblico e ordinato permette a degli estranei di mettersi d’accordo su quale pagamento sia arrivato per primo, senza una banca. Non protegge un pagamento che non è ancora nel registro, né uno che sta su una catena economica da riscrivere, e da questo discendono alcune abitudini.
- Un pagamento non confermato può ancora essere sostituito o scartato: trattalo come una promessa in sospeso.
- Proporziona l’attesa all’importo: più la somma è alta, più conferme servono prima di rilasciare merce o fondi.
- Una piccola catena proof of work richiede molte più conferme di Bitcoin, perché il suo hashrate costa poco da noleggiare.
- Un pagamento crypto confermato a un truffatore non si può stornare: controlla l’indirizzo e il destinatario prima di inviare.
- Su Ethereum una transazione in attesa può essere sostituita da un’altra con lo stesso nonce; su Bitcoin qualunque transazione non confermata può essere sostituita con una commissione più alta.
La prossima lezione di questo percorso riguarda la finalità e le riorganizzazioni: quanto in profondità può arrivare una reorg sulle diverse catene, e quando un pagamento si può dire definitivo e non soltanto molto probabilmente stabile.
