Limitare i dati arbitrari è un pendio scivoloso verso la censura a livello di protocollo. La forza di Bitcoin sta nel rifiuto di discriminare tra utenti o casi d'uso.
Live estimate to the BIP-110 fork block, following the same countdown logic used by jlopp.github.io/knotzi-death-march.
Bitcoin è progettato per essere un "tubo stupido". Definendo certi dati come "spam", il BIP-110 introduce una morale umana soggettiva nel layer base. Se oggi possiamo filtrare immagini, cosa verrà filtrato domani?
Rif: Adam Back (Blockstream) → Pagina completa dell'argomento →Man mano che il sussidio di blocco si avvicina allo zero, Bitcoin deve fare affidamento sulle fee. Le inscription hanno pagato oltre 500 milioni di dollari ai miner. Il BIP-110 rimuove questo reddito, rendendo la rete più vulnerabile agli attacchi del 51%.
Rif: Report sulla Sicurezza dei Miner → Pagina completa dell'argomento →I filtri non fermano i dati: li spingono sottoterra. Il BIP-110 incentiva pagamenti "fuori banda", in cui gli utenti pagano privatamente i miner per includere dati, creando un mercato centralizzato e opaco per lo spazio nei blocchi.
Pagina completa dell'argomento →"È un tentativo da linciaggio collettivo di imporre cambiamenti per cui non esiste consenso... il BIP-110 sarebbe un attacco alla credibilità di Bitcoin come riserva di valore neutrale."
I vincoli tecnici della proposta comportano rischi che vanno oltre la semplice rimozione dello "spam".
I limiti sulla profondità dell'albero di script pensati per fermare le inscription sono gli stessi strumenti usati per BitVM e smart contract avanzati. Il BIP-110 potrebbe involontariamente "bloccare" il futuro della scalabilità di Bitcoin.
Rif: Critica di Jameson Lopp → Pagina completa sulle conseguenze →Cambiare retroattivamente ciò che è "standard" può rendere non spendibili transazioni prefirmate o wallet con timelock. Secondo i critici, questo equivale a una confisca forzata della proprietà degli utenti.
Rif: Analisi di The Bitcoin Manual → Pagina completa sulle conseguenze →Basate sulle note ai miner di Jason Hughes del 15 luglio 2026, queste obiezioni si concentrano su ciò che BIP-110 cambia per produttori di blocchi, scoperta delle fee, coordinamento e superficie politica di attacco nel lungo periodo.
BIP-110 prova a bloccare uno stile di inserimento dei payload, ma i dati arbitrari possono migrare verso altre costruzioni di script e altri pattern di transazione. Questo lascia ai miner il rischio di coordinamento senza rimuovere davvero la domanda sottostante.
Rif: Jason Hughes, note ai miner →Se relay pubblico e tooling dei wallet rifiutano alcune transazioni, gli utenti grandi possono comunque aggirare quel percorso e negoziare direttamente con miner o pool. Il risultato è meno trasparenza sulle fee e più vantaggio per gli insider.
Rif: Jason Hughes, note ai miner →Una volta che un soft fork viene usato per vietare un uso sgradito del blockspace, gli argomenti futuri smettono di essere strettamente tecnici. I miner diventano il punto di pressione per ogni nuova campagna su ciò che Bitcoin dovrebbe o non dovrebbe permettere.
Rif: Jason Hughes, note ai miner →Un rollout controverso costringe miner e pool a indovinare quale chain vincerà, come reagiranno gli exchange e se il rischio di reorg aumenterà. BIP-110 non è solo una policy: è un evento di rischio operativo per chi protegge la chain.
Rif: Jason Hughes, note ai miner →La domanda che paga fee resta comunque domanda, anche quando alcuni utenti non apprezzano l'applicazione che consuma blockspace. Sovrascrivere quel segnale di mercato con preferenze sociali indebolisce la credibilità dell'asta neutrale di Bitcoin per l'inclusione.
Rif: Jason Hughes, note ai miner →Più Bitcoin dipende da filtri personalizzati, flussi privati e coordinamento su chain controverse, più il vantaggio si sposta verso grandi pool con relazioni più profonde e migliore postura legale o comunicativa. Gli operatori più piccoli contano meno ma portano lo stesso rischio di consenso.
Rif: Jason Hughes, note ai miner →Alcune delle critiche pubbliche più nette apparse su blog, copertura giornalistica e commenti online.
Nel suo saggio del 23 febbraio 2026, Jameson Lopp sostiene che il BIP-110 aumenta il rischio di chain split, può congelare fondi in casi limite, ostacola futuri upgrade e non riesce comunque a fermare i dati arbitrari perché gli utenti possono aggirare le regole.
Leggi: A Layman's Guide to BIP-110 →La copertura dei commenti di Adam Back su X presenta il BIP-110 come più pericoloso del problema che tenta di risolvere: avverte che danneggerebbe la credibilità di Bitcoin e potrebbe congelare alcuni UTXO tramite restrizioni di consenso.
Leggi: Copertura dell'Opposizione di Adam Back →The Bitcoin Manual spiega che una UASF può fare pressione sui miner, ma sottolinea anche il lato negativo principale: se il supporto economico viene sovrastimato, il BIP-110 può innescare una chain minoritaria, dividere la liquidità e creare fallimenti di coordinamento nell'ecosistema.
Leggi: What Is BIP-110? →Se BIP-110 provoca uno split controverso senza replay protection, la stessa transazione può risultare valida su entrambe le chain. Questo apre la porta a replay accidentali, confusione sui depositi, false assistenze wallet e frodi in stile double-spend contro utenti ed exchange.
Leggi: Lopp su split e replay risk →Lopp cita Andreas Antonopoulos per sostenere che le spirali di purezza ideologica finiscono nell'autoparodia. In questa lettura, BIP-110 è meno una soluzione tecnica e più un tentativo politico di cancellare usi di Bitcoin sgraditi ad alcune fazioni.
Leggi: Lopp che cita Andreas sulla purezza ideologica →Lopp richiama anche il thread pubblico di Murch che contesta l'idea che BIP-110 possa vincere in sicurezza attivandosi con hashrate di minoranza. È una critica diretta alla tesi secondo cui un rollout controverso si risolverebbe in modo pulito.
Leggi: Lopp che linka la confutazione di Murch →Nel suo articolo del 23 settembre 2025, Lopp sostiene che Knots eredita un problema di fiducia di base perché i binari risultavano ancora distribuiti da infrastruttura che lui descrive come compromessa. Il punto è semplice: se l'igiene della release è debole, agli utenti viene chiesto di fidarsi di una pipeline software più rischiosa.
Leggi: It's Knot a Serious Project →Lopp critica anche Knots come fork opaco guidato da un solo maintainer: la storia dei merge è più difficile da auditare, i merge commit non sono firmati come avviene di norma in Bitcoin Core e la review upstream non si trasferisce in modo pulito. Questo conta perché i cambiamenti di consenso controversi dovrebbero subire più controllo, non meno.
Leggi: Lopp sul ciclo software di Knots →Un altro filo dell'articolo di Lopp è che la governance di Knots non è solo tecnicamente controversa ma anche politicamente carica: collega il progetto all'ostilità verso mixing, strumenti per la privacy e persino a danni collaterali per sistemi come Whirlpool e Lightning. Questo aggiunge un rischio di ecosistema più ampio del solo cambio di regole BIP-110.
Leggi: Lopp su privacy e danni di ecosistema →Nel suo post su X del 15 luglio 2026, Michael Saylor definisce BIP-110 una “Bitcoin Iatrogenic Proposal”: un trattamento che causa danno. L’obiezione è che modificare le regole di consenso di Bitcoin per affrontare dati indesiderati potrebbe arrecare più danni del problema che intende risolvere.
Leggi: Michael Saylor su X →Saylor sostiene che esistono minacce a Bitcoin più gravi dello spam e che trasformare questa disputa in un cambiamento di consenso sia il vero rischio. La sua preoccupazione è che BIP-110 invaliderebbe transazioni oggi valide e paganti fee, creando un precedente dannoso.
Leggi: Michael Saylor su X →Nel messaggio collegato, Saylor attribuisce ruoli distinti a fee, nodi, miner e holder. I cambiamenti del protocollo, afferma, devono ottenere un consenso schiacciante affinché le cattive idee falliscano prima di danneggiare Bitcoin.
Leggi: Michael Saylor su X →DathonPwn segnala un potenziale bug di consenso nell’aggiornamento tardivo a BIP-110. Nello scenario descritto, i nodi aggiornati da software precedente mantengono la cronologia della catena esistente, mentre i nodi BIP-110 installati da zero rifiutano quella stessa cronologia, con il rischio di una divisione nascosta della catena.
Leggi: DathonPwn su X →Il problema segnalato è grave perché la stessa catena storica deve essere valutata in modo coerente. Se un aggiornamento in-place accetta una cronologia che una nuova installazione rifiuta, gli operatori possono eseguire inconsapevolmente nodi che non concordano su quale catena sia valida.
Leggi: DathonPwn su X →La segnalazione evidenzia un requisito essenziale per il software di consenso: un nodo aggiornato in-place e uno sincronizzato da zero devono raggiungere lo stesso stato di consenso. Se questa proprietà viene meno, BIP-110 aggiunge incertezza operativa proprio quando la rete ha bisogno di un coordinamento affidabile.
Leggi: DathonPwn su X →