Nel cuore dell'autunno 2025, mentre il codice sorgente di Bitcoin si assestava dopo l’arrivo della versione Core v30 , una proposta spuntata da un account pseudonimo ha spaccato in due la comunità. Parliamo della Bitcoin Improvement Proposal 444 (BIP‑444) : un documento tecnico, sì, ma con effetti politici e culturali. Non è una di quelle BIP che aggiungono feature o migliorano performance. No. BIP‑444 punta a vietare temporaneamente alcune forme di transazioni per limitare gli usi considerati impropri o pericolosi del protocollo Bitcoin. Ma cosa significa davvero “vietare” su Bitcoin? E può una proposta emergere dal nulla, con il supporto di pochi, e diventare vincolante per tutti? Contesto: dati arbitrari e rischi legali Bitcoin Core v30 ha eliminato il vecchio limite di 80 byte per il campo OP_RETURN . Una decisione che ha, di fatto, spalancato la porta a ogni forma di dato inseribile in blockchain: immagini, documenti, interi file NFT. Alcuni l’hanno definita una mossa...
Nel cuore dell'autunno 2025, mentre il codice sorgente di Bitcoin si assestava dopo l’arrivo della versione Core v30, una proposta spuntata da un account pseudonimo ha spaccato in due la comunità. Parliamo della Bitcoin Improvement Proposal 444 (BIP‑444): un documento tecnico, sì, ma con effetti politici e culturali. Non è una di quelle BIP che aggiungono feature o migliorano performance. No. BIP‑444 punta a vietare temporaneamente alcune forme di transazioni per limitare gli usi considerati impropri o pericolosi del protocollo Bitcoin.
Ma cosa significa davvero “vietare” su Bitcoin? E può una proposta emergere dal nulla, con il supporto di pochi, e diventare vincolante per tutti?
Contesto: dati arbitrari e rischi legali
Bitcoin Core v30 ha eliminato il vecchio limite di 80 byte per il campo OP_RETURN. Una decisione che ha, di fatto, spalancato la porta a ogni forma di dato inseribile in blockchain: immagini, documenti, interi file NFT. Alcuni l’hanno definita una mossa libertaria, altri — come i fautori di BIP‑444 — un rischio esistenziale. Perché?
Chi gestisce un nodo Bitcoin è, tecnicamente, un archivista. Ogni nodo conserva una copia completa delle transazioni. Se queste iniziano a contenere materiale illegale, come pornografia infantile (CSAM), non basta ignorarlo. Il nodo lo scarica, lo conserva, lo trasmette. Con tutte le implicazioni penali del caso.
Ecco l’origine del problema: la presenza passiva di dati illeciti può trasformare chi mantiene l’infrastruttura in un bersaglio legale. E non per un errore, ma per aver fatto il proprio dovere.
Le misure di BIP‑444: chirurgia d’emergenza, non riforma
BIP‑444 propone un soft fork “temporaneo”, valido per circa un anno (fino al blocco 987 424), che introduce sei limitazioni tecniche. Non sono modifiche minori. Cambiano il comportamento del protocollo a livello di consenso.
-
ScriptPubKey limitati a 34 byte
Le transazioni con script di uscita più lunghi verrebbero respinte. Il classicoOP_RETURNcon 80 byte rimane — per retrocompatibilità — ma tutto ciò che supera diventa invalido. -
OP_PUSHDATA ridotto a 256 byte
Ogni istruzione può “spingere” solo piccoli frammenti di dati. Impossibile caricare immagini o file compressi con un singolo comando. -
Rifiuto dei witness version non definiti
Una stretta contro l’uso creativo di Taproot e future espansioni: se la versione del testimone non è esplicitamente supportata, la transazione è invalida. -
Merkle tree Taproot con massimo 128 script foglia
Un taglio drastico alla complessità dei contratti: meno nodi foglia, meno logiche complesse, meno margine per protocolli avanzati come BitVM. -
Eliminazione di OP_IF e OP_NOTIF in Tapscript
Le condizioni “se… allora” diventano proibite. Si tratta di un colpo diretto agli Ordinals, agli NFT e agli script condizionali su Taproot. -
Scadenza automatica
Alla fine del periodo previsto, tutto torna com’era. A meno che non venga approvato un BIP successivo.
La logica? “Comprare tempo”, ridurre la superficie di attacco e prevenire il collasso della decentralizzazione sotto il peso delle responsabilità legali.
Chi c’è dietro (e chi contro)
L’autore formale della proposta è Dathon Ohm, un nome apparso dal nulla, senza storia, senza contributi precedenti. Dietro, però, si scorge l’ombra lunga di Luke Dashjr: veterano dello sviluppo di Bitcoin Core, voce nota per la sua crociata contro gli abusi di Taproot.
Dashjr l’ha definita una misura “semplice ma sufficiente”. In realtà, semplice non è, e sufficiente nemmeno. Ma la sua affermazione segnala una cosa: c’è una parte della comunità — piccola ma influente — disposta a usare modifiche di consenso per difendere il protocollo da sé stesso.
Dall’altra parte, le critiche non sono tardate:
-
Peter Todd ha ironicamente incluso l’intero testo di BIP‑444 in una transazione conforme, dimostrando quanto sia facile aggirare le restrizioni.
-
Jameson Lopp ha ricordato che i nodi accettano le regole di consenso, non le leggi locali. Il rischio di contenuti illegali, secondo lui, non giustifica la censura.
-
BitMEX Research ha paventato un rischio paradossale: che proprio BIP‑444 possa incentivare l’inserimento di CSAM per provocare attacchi di riorganizzazione e doppie spese.
E poi c’è la questione etica: il linguaggio del BIP parla di “obbligo morale e legale” ad accettare il soft fork. Un tono minaccioso, secondo molti. Come se rifiutare l’aggiornamento fosse una forma di eresia.
Neutralità del protocollo vs. responsabilità penale
Il nodo del problema è tutto qui: Bitcoin è neutrale, o deve difendersi da usi impropri?
Finora, la neutralità ha vinto. Le transazioni non si giudicano per il contenuto, ma per la forma: valide o invalide. BIP‑444 cambia le regole per paura del contenuto.
È un precedente pericoloso? O è il solo modo per evitare che la rete diventi ingestibile?
Il dibattito non è solo tecnico. È filosofico.