📖 Introduzione: Bitcoin, Satoshi e le “imperfezioni utili”

Bitcoin nasce nel 2008 dalla visione di Satoshi Nakamoto e, a distanza di anni, continua a essere oggetto di studio non solo per ciò che è, ma anche per ciò che avrebbe potuto essere.
La riflessione su possibili alternative non è una proposta di cambiamento: al contrario, serve a comprendere meglio perché Bitcoin funziona, quali compromessi incorpora e quali scenari teorici sarebbero stati possibili.

Un punto centrale, infatti, è che la forza di Bitcoin risiede proprio nella stabilità delle regole, anche se non perfette. È preferibile un sistema imperfetto ma stabile rispetto a uno teoricamente perfetto ma continuamente modificabile e quindi instabile.

💡 Regole fisse, nonostante le imperfezioni

Qualsiasi ipotesi di “cosa sarebbe stato meglio fare” in Bitcoin va letta con questa premessa fondamentale:

• Non è una richiesta di cambiare Bitcoin oggi.

• Bitcoin trova valore proprio nel fatto che le sue regole sono prevedibili, rigide e difficili da modificare.

• Anche scoprendo imperfezioni, è spesso meglio non intervenire, perché ogni modifica introduce rischi per il consenso e la sicurezza.

Immaginare un dialogo con Satoshi nel 2008 serve quindi solo come esercizio teorico: è impossibile sapere se eventuali miglioramenti di design avrebbero portato a un sistema più robusto oppure, al contrario, ne avrebbero impedito l’adozione.

⚡ Halving e “numeri magici”: meccanismi non continui

Bitcoin utilizza vari meccanismi di equilibrio economico che non sono “smooth”, cioè non variano in modo continuo, ma a scatti. L’esempio più evidente è:

• Halving: ogni 210.000 blocchi (circa 4 anni) la ricompensa per blocco viene dimezzata di colpo.

Questa struttura crea:

• Una politica monetaria a gradini: periodi di 4 anni con determinate emissioni, seguiti da un taglio netto.

• Un forte elemento di attesa e narrativa (l’Halving come “evento olimpico” o momento simbolico di mercato).

Tuttavia, dal punto di vista economico, si potrebbe immaginare un modello alternativo dove:

• L’emissione sia più graduale, con una riduzione continua anziché a scalini.

• Si riducano gli shock improvvisi di offerta e di profittabilità per i miner.

Bitcoin contiene anche altri “numeri magici”, come:

• I 210.000 blocchi tra un halving e l’altro.

• I 2016 blocchi per l’aggiustamento della difficoltà.

Questi parametri potevano essere concepiti in modo più dinamico o parametrico, ma la scelta di valori fissi e semplici ha garantito una maggiore comprensibilità e prevedibilità nelle fasi iniziali del protocollo.

🛠️ Difficoltà ogni 2016 blocchi: stabilità contro reattività

Il meccanismo di adjustment della difficoltà in Bitcoin funziona così:

• Ogni 2016 blocchi (circa due settimane), la rete ricalcola la difficoltà di mining per mantenere un tempo medio di 10 minuti per blocco.

Questo design è robusto, ma comporta alcuni scenari problematici:

• In caso di crollo improvviso dell’hashrate (molti miner che spengono le macchine), servirebbero comunque 2016 blocchi per adeguare la difficoltà.

• Questi blocchi arriverebbero però molto più lentamente del solito, causando una fase di blocchi rari e rete rallentata.

Un sistema alternativo potrebbe prevedere:

• Un aggiustamento della difficoltà a ogni blocco, molto più reattivo.

Questo avrebbe permesso di reagire meglio a shock sull’hashrate, ma:

• Aumenta la complessità dell’algoritmo.

• Potrebbe introdurre nuove superfici di manipolazione o instabilità.

💰 Divisibilità, Satoshi e fine dell’emissione

Bitcoin oggi è misurato in numeri interi di satoshi:

• 1 Bitcoin = 100.000.000 satoshi.

• Non è possibile andare “sotto” il satoshi con il protocollo attuale.

Questo non rappresenta un problema oggi, ma potrebbe esserlo in futuro se:

• Molti bitcoin venissero persi in modo definitivo.

• Il prezzo di BTC salisse così tanto che 1 satoshi valesse, ad esempio, 100 dollari o più.

Una alternativa di design avrebbe potuto essere:

• Usare frazioni invece che interi per rappresentare le unità.

• Permettere una divisibilità infinita, evitando limiti rigidi al “granello” minimo.

Inoltre, con un modello frazionario, l’emissione avrebbe potuto:

• Non fermarsi mai in modo netto, ma avvicinarsi asintoticamente ai 21 milioni senza raggiungerli.

• Mantenere il limite teorico di 21 milioni, ma con una coda infinitesimale di emissione.

Questo avrebbe avuto un vantaggio ulteriore:

• Garantire per sempre un minimo sussidio inflattivo per i miner, diminuendo le paure legate a un futuro sostentamento solo tramite fee.

🔑 Fee, sicurezza e il problema del “fee sniping”

Tra le discussioni sul lungo termine di Bitcoin c’è il tema della sicurezza senza block subsidy, cioè quando la ricompensa per blocco sarà praticamente nulla e i miner saranno pagati solo tramite commissioni di transazione (fee).

In questo scenario si ipotizza un rischio chiamato fee sniping:

• Se un blocco contiene fee molto alte e non c’è quasi più sussidio inflattivo, un miner potrebbe avere l’incentivo a costruire un blocco alternativo al posto di proseguire sulla catena più lunga, cercando di “rubare” quelle fee.

Oggi questo fenomeno non si osserva in modo rilevante perché:

• C’è ancora una componente significativa di inflazione programmata nella ricompensa.

Un modello con una emissione infinitesimale perpetua avrebbe potuto:

• Mantenere sempre un minimo sussidio.

• Ridurre il peso relativo delle sole fee nei calcoli di convenienza economica per i miner.

Le paure sulla “mancanza di sicurezza” in futuro potrebbero essere in parte esagerate, ma è indubbio che si tratti di un tema di ricerca aperta e di analisi a lungo termine.

🧠 Full validation vs client-side validation: un’altra possibile Bitcoin

Nel design attuale, Bitcoin utilizza una validazione globale:

• Ogni transazione include tutti i dati rilevanti (input, output, script, firme).

• Questi dati sono inseriti nella blockchain pubblica.

• Tutti i nodi completi verificano tutte le regole per sempre.

Esiste però un paradigma alternativo, noto come client-side validation (validazione lato utente), alla base di proposte come quelle di Peter Todd e progetti come RGB:

• La logica della transazione (input, output, script, condizioni) non viene pubblicata integralmente sulla blockchain.

• La blockchain contiene solo un commitment crittografico (ad esempio, un Merkle root o un hash).

• Tutti i dettagli necessari alla validazione sono scambiati direttamente tra le parti coinvolte nella transazione.

In pratica:

• Chi invia una transazione fornisce al destinatario tutta la storia rilevante (input, output, script, firme, ecc.).

• I miner vedono solo un oggetto opaco, a cui applicano poche regole base (ad esempio il pagamento delle fee), inserendolo nel blocco.

Quando il destinatario vede che il proprio commitment è incluso in un blocco, ha la certezza che:

• Non c’è un double spending rispetto alla storia che conosce.

• La transazione è stata confermata secondo le regole che lui stesso può verificare localmente.

Vantaggi di questo design:

• Scalabilità di ordine di grandezza

  superiore, perché la blockchain contiene meno dati dettagliati.

• Privacy molto più forte: i miner e i nodi vedono solo hash e non l’intero contenuto delle transazioni.

• Resistenza alla censura elevata: se un miner non può interpretare il contenuto della transazione, diventa più difficile censurarla per motivi di contenuto.

Limiti e complessità introdotte:

• Per ricevere, l’utente deve essere online (come in Lightning Network).

• La gestione dei backup diventa molto più onerosa: non basta un seed HD, ma occorre mantenere l’intera storia delle transazioni rilevanti.

• Non è possibile affidarsi semplicemente a un wallet deterministico gerarchico per ricostruire l’intero stato.

Per questi motivi, un Bitcoin nato fin da subito in modalità client-side validated sarebbe stato:

• Più scalabile e più privato sul piano teorico.

• Ma anche più complesso da comprendere, sviluppare e usare nelle fasi pionieristiche.

È plausibile che questa complessità iniziale avrebbe potuto frenare l’adozione o addirittura impedire che Bitcoin prendesse piede come è successo nella realtà.

⚡ Paralleli con Lightning Network e il progetto RGB

Alcune limitazioni ipotizzate per un Bitcoin “client-side validated” sono in realtà già visibili in sistemi costruiti sopra Bitcoin, come Lightning Network:

• Per ricevere pagamenti Lightning occorre essere online.

• È necessario gestire con attenzione i backup dei canali per evitare la perdita di fondi.

Il progetto RGB riprende esplicitamente il concetto di client-side validation:

• Crea token e asset che vengono validati lato client, usando Bitcoin come strato di commitment.

• Sfrutta gli hash sulla blockchain per ancorare stati e passaggi di proprietà, mantenendo però i contenuti fuori dalla chain pubblica.

In un futuro ipotetico, se fosse possibile collegare in modo sicuro questi token completamente validati lato client a Bitcoin stesso, si potrebbe ottenere una forma di:

• Bitcoin client-side validated, con privacy e scalabilità molto superiori, pur mantenendo la sicurezza crittografica di base.

🛠️ Modularità del codice: dal “blob” iniziale alla separazione dei ruoli

Un altro aspetto spesso sottovalutato riguarda la struttura del codice originario di Bitcoin.
Satoshi non era solo un programmatore, ma anche un progettista di sistemi e un pensatore economico. Il risultato è che il primo client Bitcoin:

• Era un grande blocco monolitico di codice.

• Conteneva funzioni molto eterogenee, inclusi persino un poker game e un mercato decentralizzato, poi rimossi.

Con il tempo, la comunità ha iniziato un processo di modularizzazione:

• La parte wallet è stata, di fatto, separata: molti utenti usano software dedicati (Sparrow, Specter, BlueWallet, app Lightning, ecc.).

• I miner non usano più Bitcoin Core “puro” per il mining, ma varianti specializzate del software.

• Altre componenti come la gestione della mempool vengono sempre più isolate e rese sostituibili.

L’ideale architetturale verso cui si tende oggi è:

• Una libreria di consenso minimale, che faccia pochissime cose, ma in modo estremamente affidabile.

• Strati separati per wallet, interfacce utente, mining, mempool policy, funzionalità di messaggistica (es. package relay), Lightning e altri protocolli di secondo livello.

Se Satoshi avesse iniziato direttamente con una elegante libreria di consenso in C++ e nient’altro, è però probabile che:

• Nessuno avrebbe costruito rapidamente gli altri pezzi mancanti.

• L’adozione iniziale di Bitcoin sarebbe stata ancora più lenta o incerta.

Anche in questo caso,

quindi, la scelta “sporca ma funzionante” del primo client monolitico ha probabilmente favorito l’avvio del sistema, lasciando alla comunità il compito di raffinare e modularizzare nel tempo.

🔍 Il peso del senno di poi

Molte delle considerazioni fin qui elencate si basano su analisi retrospettive:

• Guardando indietro, è facile individuare punti dove un’alternativa avrebbe potuto sembrare migliore.

• Non è però possibile sapere se quei miglioramenti teorici avrebbero rotto l’equilibrio sociale necessario alla nascita e alla diffusione di Bitcoin.

In diversi casi, anzi, la maggiore complessità dei design alternativi suggerisce che Bitcoin, se concepito in quel modo fin dall’inizio, avrebbe potuto:

• Non decollare come rete globale aperta.

• Restare un esperimento di nicchia per pochi specialisti.

Il dato certo è che:

• La versione effettivamente lanciata da Satoshi ha funzionato, nonostante le sue imperfezioni.

• Le regole stabili hanno permesso al sistema di crescere senza continui conflitti di governance.

👉 In sintesi:

Bitcoin, così com’è, rappresenta un compromesso riuscito tra semplicità, sicurezza e praticità di implementazione.
A livello puramente teorico:

• La politica monetaria avrebbe potuto essere più continua e meno legata a “numeri magici”.

• La divisibilità avrebbe potuto essere infinita, con un’emissione asintotica che non termina mai in modo netto.

• La sicurezza di lungo periodo avrebbe potuto includere un sussidio minimo perpetuo, riducendo le paure legate a un sistema basato solo sulle fee.

• Un modello di client-side validation avrebbe reso il sistema più privato e scalabile, a costo di una complessità molto maggiore per gli utenti.

• Il codice avrebbe potuto nascere più modulare, ma probabilmente questo avrebbe rallentato o ostacolato l’adozione.

Il paradosso è che proprio queste “imperfezioni” iniziali hanno consentito a Bitcoin di essere comprensibile, utilizzabile e adottabile nei suoi primi anni di vita.
Oggi l’attenzione non è tanto nel riscrivere le regole fondamentali, quanto nel costruire strati superiori (Lightning, RGB e altri protocolli) che permettano di esplorare quelle idee alternative senza compromettere il cuore stabile del protocollo creato da Satoshi Nakamoto. ⚡