Un caso per regole neutrali, consenso solido, mercati aperti e innovazione senza permessi
Molti Bitcoiner che rispetto sostengono BIP 110. Vogliono mantenere la validazione accessibile, proteggere gli operatori di nodi da costi e contenuti indesiderati, preservare pagamenti accessibili e mantenere Bitcoin focalizzato sulla moneta solida piuttosto che sull'archiviazione generica di dati. Sono preoccupazioni serie. Condivido gli obiettivi. Non sono d'accordo sul rimedio. (GitHub
Questo articolo critica la proposta, non le persone dietro di essa. Presumo la buona fede. Bitcoin è più forte quando possiamo dissentire vigorosamente senza scambiare alleati per nemici.
Né questa è una difesa di ogni iscrizione, token, file o applicazione. Alcuni possono essere frivoli, dannosi o fraudolenti. La domanda è più ristretta: un uso controverso di transazioni attualmente valide e che pagano commissioni dovrebbe essere affrontato modificando il consenso?
Non tutte le ragioni qui sotto hanno lo stesso peso, e diverse si rafforzano a vicenda. Il caso è cumulativo.
Cosa Propone BIP 110
Questo articolo affronta BIP 110 versione 1.0.0, il "Softfork Temporaneo per Dati Ridotti," avanzato a Complete il 25 giugno 2026. Secondo BIP 3, Complete significa che gli autori hanno concluso il lavoro pianificato e ne raccomandano l'adozione. Non significa che Bitcoin abbia adottato la proposta o che la comunità abbia raggiunto il consenso. Il repository dei BIP dichiara esplicitamente che la pubblicazione non stabilisce che una proposta sia buona, abbia il consenso della comunità o stia per essere adottata. (GitHub
Durante un periodo attivo di circa un anno, BIP 110 aggiungerebbe sette restrizioni di consenso. Limiterebbe i nuovi scriptPubKey a 34 byte, con un'eccezione di 83 byte per OP_RETURN; limiterebbe molti payload inviati e elementi witness degli argomenti script a 256 byte; proibirebbe di spendere versioni witness e Tapleaf indefinite pur consentendo ancora la creazione di tali output; proibirebbe l'annex Taproot; limiterebbe i blocchi di controllo Taproot a 257 byte; rifiuterebbe Tapscript contenenti opcode OP_SUCCESSx; e rifiuterebbe esecuzioni Tapscript di OP_IF o OP_NOTIF. (GitHub
La proposta fa salvi gli output di transazione non spesi creati prima dell'attivazione. Questa è una salvaguardia importante. Non sostengo che BIP 110 confischi ampiamente bitcoin esistenti. La mia obiezione è più ristretta: rimuove in modo prospettico funzionalità di transazione attualmente valide, può influenzare rari flussi di lavoro pre-firmati che attraversano l'attivazione, riduce l'opzionalità tecnica e stabilisce un precedente per l'uso di restrizioni di consenso per scoraggiare una categoria di uso altrimenti valido. (GitHub
BIP 110 propone anche un'implementazione BIP 9 modificata. Utilizza una soglia di segnalazione dei minatori del 55 percento, rispetto alla soglia del 95 percento specificata in BIP 9; elimina il timeout convenzionale e lo stato FAILED; aggiunge un periodo di segnalazione obbligatoria; garantisce il lock-in sulla catena di enforcement entro un'altezza specificata; e aggiunge un nuovo stato EXPIRED dopo 52.416 blocchi attivi. (GitHub
Come qualsiasi soft fork, BIP 110 non è imposto da un'autorità centrale. Gli utenti scelgono quale software e quali regole applicare. Il rischio sorge quando partecipanti economicamente significativi applicano regole materialmente diverse, creando pressione, incertezza o una scissione della catena.
Gli autori forniscono un'implementazione di riferimento, vettori di test, una motivazione dettagliata e una discussione onesta dei compromessi. Questi sono punti di forza sostanziali del documento. La proposta sostiene che l'urgenza e la durata temporanea giustifichino la soglia più bassa e le restrizioni intenzionalmente semplici e brusche. Rispetto la preoccupazione e il lavoro. Non sono d'accordo sul calcolo del rischio. (GitHub
I. Neutralità e Principi Fondamentali
1. Il consenso è l'intervento più potente di Bitcoin. Un soft fork rende alcuni blocchi che erano validi secondo le regole precedenti non validi per i nodi aggiornati. Quel potere dovrebbe essere riservato a fallimenti chiari, seri e ampiamente compresi.
2. Non è una riparazione per un fallimento di consenso stabilito. BIP 110 non corregge inflazione, validazione delle firme, doppia spesa o un bug critico noto. Affronta un'esternalità e un caso d'uso controversi, quindi l'onere della prova dovrebbe essere particolarmente alto.
3. Eleva un giudizio contestato a legge del protocollo. La proposta sposta una disputa sull'uso legittimo e le esternalità dalla politica di relay, dalla politica mineraria e dai mercati alla validità del consenso.
4. Bitcoin non può leggere l'intento. La rete non può sapere se i byte rappresentano un'immagine, una prova, un contratto, metadati, un record di autenticazione o un'applicazione futura.
5. I proxy strutturali creano rischio collaterale. Poiché l'intento non può essere conosciuto, la proposta limita forme tecniche che possono servire sia scopi sfavoriti che legittimi.
6. Un messaggio sociale non è una base sufficiente per un cambiamento di consenso. La specifica tratta esplicitamente l'attivazione come un modo per comunicare che l'archiviazione di dati è indesiderata. Il consenso dovrebbe essere cambiato per ragioni tecniche o monetarie convincenti, non principalmente per esprimere disapprovazione. (GitHub
7. La disapprovazione non è invalidità. Una transazione può essere banale, speculativa, offensiva o dispendiosa e seguire comunque le regole e pagare la commissione richiesta per l'inclusione.
8. Restringe la libertà economica prospettica sulla catena BIP 110. Gli UTXO pre-attivazione sono fatti salvi, ma gli utenti che creano UTXO durante il periodo attivo avrebbero meno modi validi per strutturarli e spenderli rispetto al consenso esistente.
9. I sistemi senza permessi devono tollerare la sperimentazione non approvata. Richiedere agli innovatori di dimostrare che il loro uso è valido prima di costruire inverte il significato di innovazione senza permessi.
10. Capovolge il conservatorismo del protocollo. Il conservatorismo al livello base dovrebbe significare riluttanza ad alterare il consenso, non entusiasmo nell'alterare il consenso a favore di una filosofia d'uso conservatrice.
II. L'Onere della Prova Non è Stato Soddisfatto
11. "Spam" non è un primitivo di consenso. Non esiste un opcode che possa distinguere lo spam dall'utilità. Quelle etichette derivano dal giudizio umano.
12. "Monetario" e "non monetario" non sono nettamente separabili. Un canale di pagamento, una prova di riserve, una politica di custodia, un contratto intelligente o un impegno di regolamento è sia attività finanziaria che dati.
13. I casi d'uso noti non sono l'intero spazio di progettazione. La proposta dice di preservare tutti i casi d'uso monetari noti. L'innovazione è definita da ciò che non è ancora noto.
14. Il BIP stesso non quantifica l'onere del nodo che rimuoverebbe. Descrive i costi ma non stima la larghezza di banda, l'archiviazione, il carico di validazione, le soglie hardware o il numero di operatori di nodi probabilmente guadagnati o persi.
15. Non quantifica il beneficio di decentralizzazione. L'affermazione che BIP 110 migliorerebbe la decentralizzazione non è accompagnata da un modello o obiettivo misurabile.
16. Non quantifica il sollievo sui pagamenti. Non stima quanto le commissioni di transazione diminuirebbero, per quanto tempo o quanti utenti di pagamenti ne trarrebbero beneficio.
17. Combina costi distinti in un'unica diagnosi. La crescita dello stato UTXO, la larghezza di banda di sincronizzazione iniziale, l'archiviazione di archivio, l'onere di relay e il tempo di validazione hanno cause diverse e possono richiedere rimedi diversi.
18. L'urgenza è affermata piuttosto che definita operativamente. La proposta definisce la situazione urgente e una crisi, ma non fornisce alcuna soglia oggettiva in cui l'intervento di consenso diventa necessario.
19. Un limite storico della politica di relay non è prova di un limite di consenso ottimale. Un default di 83 byte può essere una politica utile senza diventare una regola di validità del blocco senza tempo.
20. Il limite di 256 byte è euristico. La motivazione lo mette in relazione in parte con la dimensione delle immagini compresse e con grandi interi crittografici, ma non stabilisce 256 byte come confine ottimale tra sicurezza e innovazione. (GitHub
III. L'Ambito Tecnico è Troppo Ampio
21. Sette cambiamenti di consenso separati sono raggruppati insieme. I partecipanti non possono sostenere una restrizione e rifiutarne un'altra. Devono accettare o rifiutare il pacchetto.
22. La preoccupazione tecnica più forte è raggruppata con restrizioni non correlate. I grandi scriptPubKey possono aumentare i costi di stato UTXO e di validazione. Se ciò crea un pericolo misurabile, merita una proposta di ambito ristretto da sola, non il supporto automatico per sei restrizioni aggiuntive. (GitHub
23. La politica OP_RETURN di 83 byte diventa consenso. Ciò converte una preferenza di relay e mining configurabile in una regola di validità del blocco.
24. I limiti di 256 byte vincolano primitive generali. Prendono di mira l'archiviazione di dati limitando ampie classi di payload inviati e elementi witness degli argomenti script.
25. Spendere versioni witness e Tapleaf indefinite sarebbe disabilitato. Questi spazi sono inutilizzati oggi in parte perché sono riservati per aggiornamenti futuri.
26. L'annex Taproot sarebbe disabilitato. BIP 341 riserva l'annex per estensioni future. Anche se gli utenti non dovrebbero impiegarlo prima che il suo significato sia definito, chiudere un percorso di aggiornamento deliberato dovrebbe richiedere una giustificazione eccezionale. (GitHub
27. La profondità del Taptree sarebbe ridotta. Un limite del blocco di controllo di 257 byte limita i percorsi script rivelati a sette livelli e può vincolare alberi script complessi.
28. OP_SUCCESSx sarebbe disabilitato anche in rami non eseguiti. BIP 342 ha creato questi opcode come hook di aggiornamento puliti per futuri soft fork. (GitHub
29. OP_IF e OP_NOTIF eseguiti sarebbero proibiti in Tapscript. Gli autori li considerano ridondanti e comunemente abusati, ma riconoscono anche usi sperimentali e possibili efficienze Miniscript.
30. La proposta accetta apertamente la bruschezza in cambio di velocità. La sua motivazione dice che un approccio più equilibrato richiederebbe più sviluppo e revisione, quindi sceglie restrizioni più semplici destinate a un'implementazione più rapida. L'urgenza non è un sostituto per la precisione nel codice di consenso. (GitHub
IV. Sacrifica Compatibilità e Opzionalità Futura
31. Chiude diversi percorsi di aggiornamento contemporaneamente. Annex, versioni witness future, versioni Tapleaf future e OP_SUCCESSx fanno tutti parte dello spazio di progettazione riservato di Bitcoin. (GitHub
32. Riservato non significa inutile. Significa che i progettisti precedenti hanno deliberatamente preservato il valore dell'opzione per esigenze che non erano ancora emerse.
33. Una chiusura di un anno può comunque interrompere le tempistiche di sviluppo. Gli autori si aspettano che i futuri soft fork richiedano più di un anno di coordinamento, ma questa è una stima, non una garanzia.
34. Può complicare progetti in stile BitVM. La specifica riconosce che il limite del blocco di controllo potrebbe ostacolare il contracting off-chain avanzato.
35. Può influenzare i Tapleaf generati da Miniscript. La proposta riconosce che alcuni output del compilatore possono contenere OP_IF e necessiterebbero di aggiustamenti.
36. Richiede modifiche negli strumenti wallet interessati. La sezione di compatibilità all'indietro afferma che il compilatore Miniscript avrebbe bisogno di modifiche mentre le regole sono attive.
37. Crea un rischio di accesso ai fondi ristretto ma ammesso. Il BIP identifica candidamente rari scenari Taproot pre-firmati in cui gli UTXO post-attivazione potrebbero essere congelati o spesi inaspettatamente.
38. La salvaguardia è preziosa ma non un isolamento completo. Gli UTXO pre-attivazione sono protetti, ma i flussi di lavoro che creano o spendono output interessati durante l'implementazione possono comunque incontrare nuovi vincoli.
39. Si consiglia agli utenti di migrare fondi potenzialmente interessati. Una proposta che richiede anche a una ristretta classe di utenti di migrare non è un filtro senza costi.
40. "Nessun caso d'uso noto" non è una prova di sicurezza. I sistemi privati, i contratti non pubblicati, i wallet sperimentali e i protocolli futuri non sono completamente osservabili. (GitHub
V. Le Regole di Consenso Temporanee Creano Ancora Complessità Reale
41. Il codice di consenso temporaneo è ancora codice di consenso. Deve essere specificato, implementato, revisionato, testato, distribuito, monitorato e successivamente ritirato.
42. La salvaguardia rende la validità dipendente dalla storia. La stessa costruzione di spesa può essere trattata diversamente a seconda di quando è stato creato l'UTXO.
43. Le regole dipendenti dalla storia aumentano la complessità di implementazione. Ogni implementazione deve identificare l'altezza di creazione dell'UTXO rilevante e applicare le esenzioni in modo identico.
44. L'attivazione crea un confine critico. Il software e gli attori economici devono concordare su quando iniziano le nuove restrizioni.
45. La scadenza ne crea un altro. Devono anche concordare su quando le restrizioni terminano e il comportamento precedentemente limitato torna ad essere valido.
46. BIP 110 aggiunge un nuovo stato EXPIRED. Ciò estende la macchina a stati di implementazione familiare con un nuovo comportamento di consenso.
47. Rimuove l'esito FAILED convenzionale. L'implementazione proposta non può semplicemente scadere nel modo ordinario di BIP 9.
48. Crea diverse finestre di coordinamento. La segnalazione volontaria, la segnalazione obbligatoria, il lock-in, l'attivazione e la scadenza introducono ciascuna opportunità di divergenza. (GitHub
49. Le regole temporanee possono lasciare artefatti permanenti. Il codice del wallet, le procedure operative, i contratti e i controlli di rischio istituzionale possono richiedere modifiche che sopravvivono all'implementazione.
50. Più rami di consenso significano più superficie di bug. I vettori di test riducono il rischio noto, ma non possono enumerare ogni interazione privata o futura.
VI. Gli Effetti Economici e di Sicurezza Sono Incerti
51. L'esternalità del nodo è reale ma eterogenea. Ogni nodo a piena validazione deve scaricare e verificare i blocchi, mentre i nodi potati possono scartare i vecchi dati grezzi del blocco e limitare l'archiviazione storica. I costi rilevanti dovrebbero essere misurati separatamente. (Bitcoin Core
52. Il problema del beneficiario della commissione non è unico per le transazioni di dati. I minatori raccolgono commissioni mentre i validatori sopportano alcuni costi per ogni transazione. La magnitudine può differire, ma la struttura di base è universale.
53. I costi tecnici dovrebbero essere misurati direttamente. Per una data quantità di dati e lavoro di validazione, i costi delle risorse derivano da byte, stato, calcolo e larghezza di banda, non da se gli osservatori approvano lo scopo della transazione.
54. BIP 110 non può eliminare l'incorporamento di dati. La specifica riconosce che gli utenti possono dividere i dati in pezzi più piccoli o mascherarli all'interno di strutture consentite. (GitHub
55. L'elusione può rendere le transazioni meno efficienti. Le codifiche frammentate o offuscate possono consumare più struttura e complicare l'analisi senza eliminare la domanda sottostante.
56. L'effetto sulle commissioni è ambiguo. Sopprimere un uso può abbassare le commissioni di pagamento, ridurre le entrate aggregate delle commissioni, spostare la domanda verso altre codifiche o produrre una combinazione dei tre.
57. Le entrate dei minatori contano di più con il declino del sussidio. Le commissioni di transazione sono una componente della ricompensa del blocco, mentre il sussidio del blocco si dimezza ogni 210.000 blocchi. (Bitcoin Developer Docs
58. Una minore domanda aggregata di commissioni può indebolire la sicurezza al margine. Nella misura in cui BIP 110 riduce la domanda totale di commissioni piuttosto che semplicemente riallocarla, minori entrate per i minatori possono ridurre l'incentivo a impegnare potenza di hash, a parità di altre condizioni.
59. Una domanda diversificata può rendere il mercato delle commissioni più resiliente. Pagamenti, canali, sistemi di custodia, applicazioni finanziarie e altri usi non devono raggiungere il picco contemporaneamente.
60. La specifica non modella il compromesso di sicurezza. Sostiene pagamenti più economici e costi del nodo inferiori senza stimare i possibili effetti sulle entrate dei minatori, sugli investimenti in hash o sulla profondità a lungo termine del mercato delle commissioni.
VII. Esistono Migliori Strumenti di Mercato e Politica
61. Bitcoin ha già un vincolo di capacità neutrale rispetto al contenuto. Il peso del blocco impone un limite comune alla capacità di transazione di ogni blocco. (GitHub
62. Le commissioni già razionano lo spazio di blocco scarso. Gli utenti esprimono urgenza facendo offerte, e i minatori selezionano transazioni valide secondo le proprie politiche.
63. Il limite del blocco e il mercato delle commissioni non chiedono agli utenti di dichiarare lo scopo. Applicano la validità tecnica e i limiti delle risorse piuttosto che un test semantico per stabilire se una transazione è sufficientemente monetaria.
64. La politica di relay rimane uno strumento meno coercitivo. Le implementazioni e gli operatori di nodi possono scegliere quali transazioni non confermate inoltrare senza ridefinire i blocchi validi. La politica del data-carrier di Bitcoin Core è configurabile. (GitHub
65. La politica mineraria rimane volontaria. I minatori possono escludere classi di transazioni dai propri modelli di blocco senza costringere ogni nodo di validazione a rifiutare blocchi che le contengono.
66. La politica è imperfetta, ma l'imperfezione non è un fallimento. L'invio diretto ai minatori può bypassare i filtri di relay. Quel limite merita analisi, non un salto automatico al divieto di consenso.
67. Nessuna transazione ha il diritto all'inclusione. Un minatore può rifiutare una transazione secondo la propria politica, ma rendere una transazione precedentemente valida non valida attraverso un fork è un atto molto più consequenziale.
68. La tariffazione delle risorse può essere migliorata senza classificare lo scopo. Se certe strutture impongono costi sproporzionati, Bitcoin può studiare limiti neutrali rispetto al contenuto o prezzi legati all'uso misurabile delle risorse.
69. Il potamento e i progetti di dati opzionali meritano una ricerca continua. Potrebbero non risolvere ogni preoccupazione, ma affrontano gli oneri di archiviazione in modo più diretto di una regola intesa in parte a segnalare che un uso è indesiderato.
70. Il BIP stesso concede che la politica è generalmente il posto giusto per combattere lo spam. La sua incapacità di garantire un filtraggio perfetto non prova da sola che il consenso debba essere usato. (GitHub
VIII. Scoraggia l'Innovazione e l'Adozione
71. Crea un effetto dissuasivo. Gli sviluppatori potrebbero evitare Bitcoin se costruzioni attualmente valide possono essere sospese attraverso il consenso per sopprimere un uso correlato.
72. Privilegia i casi d'uso esistenti. "Tutti i casi d'uso monetari noti" protegge il presente, non il futuro.
73. Distrugge il valore dell'opzione prima che il valore possa essere scoperto. Il miglior uso futuro di un hook di aggiornamento potrebbe non avere ancora un nome.
74. Le fondamenta stabili contano per i contratti a lunga scadenza. Wallet, sistemi di custodia, canali di pagamento e protocolli finanziari hanno bisogno della certezza che le strutture di transazione valide rimarranno disponibili.
75. Restringe lo spazio di progettazione degli script. Ciò può rendere alcune costruzioni più grandi, più costose, meno eleganti o temporaneamente impossibili.
76. Può ritardare la ricerca sul contracting avanzato. Il BIP accetta esplicitamente che il lavoro in stile BitVM potrebbe dover attendere o procedere su testnet e sidechain. (GitHub
77. Spinge la sperimentazione lontano da Bitcoin per consenso. Testnet e sidechain sono utili, ma i costruttori non dovrebbero essere spostati dal livello base senza un caso di sicurezza convincente.
78. I futuri sistemi di Livello 2 possono dipendere dagli hook inutilizzati di oggi. L'opzionalità del livello base può supportare la scala senza richiedere frequente attività del livello base.
79. Le applicazioni possono rafforzare la moneta. Wallet migliori, custodia, regolamento, credito, titoli e sistemi di prova possono aumentare l'utilità, la liquidità e la domanda di Bitcoin.
80. Bitcoin non deve scegliere tra moneta e tecnologia. La sua forza monetaria può essere rafforzata da una rete aperta che supporta wallet sicuri, contratti, custodia, regolamento e innovazione.
IX. Il Meccanismo di Attivazione è Troppo Aggressivo
81. La soglia del 55 percento è una deviazione importante da BIP 9. BIP 9 specifica una soglia di prontezza del minatore del 95 percento; BIP 110 propone il 55 percento.
82. Una restrizione controversa dovrebbe richiedere maggiore fiducia, non minore. La durata temporanea non rende il fallimento del coordinamento innocuo.
83. La segnalazione dei minatori non è un referendum su tutti gli utenti di Bitcoin. La potenza di hash assicura e ordina le transazioni, ma detentori, exchange, wallet, commercianti, custodi e aziende determinano quali regole e asset accettano economicamente.
84. La segnalazione obbligatoria cambia il significato della non partecipazione. Durante la finestra specificata, i nodi di enforcement rifiuterebbero i blocchi che non segnalano il bit 4.
85. L'implementazione è progettata per bloccarsi entro un'altezza predeterminata sulla catena di enforcement. Ciò è più forte della semplice osservazione della prontezza volontaria.
86. L'assenza di uno stato FAILED rimuove una via d'uscita pulita. Una proposta che non può attrarre supporto volontario sufficiente dovrebbe poter scadere senza coordinamento forzato. (GitHub
87. Il meccanismo di attivazione non può fabbricare il consenso. Può coordinare gli stati del software, ma non può creare accordo sociale ed economico.
88. L'applicazione divergente può dividere la rete. Se partecipanti economicamente significativi applicano regole di validità incompatibili, il risultato può essere una scissione della catena o un'incertezza prolungata.
89. Una scissione temporanea non sarebbe banale. Liquidità, custodia, regolamento, contabilità e fiducia degli utenti potrebbero essere tutti influenzati.
90. Il consenso solido è il sistema immunitario di Bitcoin. Abbassare l'asticella per una restrizione contestata di un caso d'uso può creare un rischio più serio del problema mirato di archiviazione dei dati.
X. Il Precedente è Più Pericoloso del Bersaglio
91. Le regole scadono, ma il precedente no. Future campagne possono citare BIP 110 come prova che il consenso può essere usato per sopprimere attività valida sfavorita.
92. La stessa logica può essere riutilizzata. Una fazione può etichettare un altro uso come non monetario, dannoso, legalmente rischioso o non supportato e cercarne l'esclusione.
93. "Uso non supportato" è una categoria espandibile. Bitcoin non ha un product manager centrale che possa definire permanentemente il suo ambito approvato.
94. I confini basati sullo scopo diventano confini politici. Una volta che la validità dipende da giudizi sull'uso legittimo, i dibattiti sul protocollo diventano competizioni su valori e potere.
95. Il bersaglio di oggi non limita il bersaglio di domani. Strumenti di privacy, nuova custodia, regolamento di stablecoin, sistemi di token, applicazioni aziendali o altri usi impopolari potrebbero affrontare argomenti simili. Questa non è una previsione. È un rischio di governance.
96. Ogni restrizione è presentata come eccezionale. I precedenti sono creati proprio dai casi che i loro sostenitori considerano unici.
97. La coesione sociale è una risorsa scarsa. Codificare una disputa culturale nel consenso può consumare fiducia e capacità di coordinamento necessarie per minacce più serie.
98. Ogni parte interessata merita di essere ascoltata. Sviluppatori, operatori di nodi, minatori, detentori, wallet, exchange, custodi, aziende e istituzioni sopportano tutti rischi e responsabilità diversi.
99. Il capitale a rischio merita considerazione, ma non deve conferire controllo. Grandi detentori, miner, exchange, custodi e aziende non possiedono il consenso. Nemmeno gli sviluppatori o i gestori di nodi che agiscono da soli. Un accordo duraturo richiede il coordinamento tra tutti loro.
100. La partecipazione aziendale è legittima quando rafforza Bitcoin. Le aziende permettono alle persone di organizzarsi all'interno della legge con scala, responsabilità, capitale e continuità. Non meritano autorità speciali, ma non dovrebbero essere trattate come estranee a una rete monetaria globale.
XI. Esiste una Strada Migliore
101. I partecipanti possono opporsi all'archiviazione dei dati senza modificare il consenso. Possono rifiutarsi di utilizzare, promuovere, indicizzare, inoltrare o minare tali dati.
102. Scelte software più restrittive possono rimanere volontarie. Implementazioni concorrenti e policy configurabili sono caratteristiche di una rete aperta, non difetti.
103. Possiamo migliorare la misurazione prima dell'intervento. Pubblicare dati riproducibili su larghezza di banda, archiviazione, tempo di validazione, crescita UTXO, spiazzamento delle commissioni ed economia dei nodi.
104. Possiamo concentrarci su costi di risorse misurabili. Una regola circoscritta legata a un rischio dimostrato di denial-of-service o di validazione è più difendibile di un pacchetto ampio basato in parte su uno scopo percepito.
105. Possiamo migliorare il posizionamento dei dati. Impegni migliori, archiviazione opzionale, potatura e architetture di Layer 2 possono ridurre gli oneri preservando la funzionalità.
106. Possiamo migliorare la trasparenza del mercato delle commissioni. Strumenti e modelli migliori possono mostrare chi paga, chi sostiene i costi e quali usi escludono effettivamente i pagamenti.
107. Possiamo preservare i punti di aggancio per gli aggiornamenti mentre la ricerca continua. La capacità inutilizzata non è necessariamente uno spreco quando protegge percorsi futuri di soft-fork.
108. Possiamo aspettare un allineamento schiacciante. Il costo dell'attesa dovrebbe essere misurato rispetto al costo di un fork non necessario. In assenza di prove convincenti di un'emergenza e di un ampio accordo, la moderazione è l'impostazione predefinita più sicura.
109. Possiamo essere in disaccordo senza trasformare gli alleati in nemici. I sostenitori di BIP 110 stanno cercando di proteggere Bitcoin. La risposta rispettosa è affrontare le loro preoccupazioni, rifiutando al contempo un rimedio che crea rischi maggiori.
110. La cura proposta è più pericolosa della malattia. BIP 110 userebbe il consenso per restringere l'attività valida, limitare le opzioni future, complicare la distribuzione e stabilire un precedente che non potrà poi cancellare. Questo lo rende una Proposta Iatrogena per Bitcoin.
Guardiani della Neutralità
La forza di Bitcoin non è che tutti siano d'accordo su ogni uso. La sua forza è che il disaccordo è contenuto da regole neutrali e da un consenso solido.
Le commissioni determinano il prezzo dello spazio nei blocchi. I nodi scelgono le policy e validano il consenso. I miner costruiscono i blocchi. I detentori allocano il capitale. Gli sviluppatori propongono codice. Le aziende costruiscono infrastrutture e applicazioni. I cambiamenti al protocollo dovrebbero prevalere solo quando validazione, sicurezza, utilità e capitale raggiungono un allineamento schiacciante.
Questa non è una difesa di ogni iscrizione, token, file o applicazione. È una difesa delle regole neutrali che permettono a Bitcoin di rimanere aperto mentre i mercati premiano ciò che è utile e abbandonano ciò che non lo è.
Bitcoin dovrebbe rimanere conservativo al livello base. Per me, questo significa rifiutare BIP 110.
Bitcoin non ha bisogno di guardiani della purezza.
Ha bisogno di guardiani della neutralità.
Fonti Primarie
Questa analisi si basa principalmente su BIP 110 versione 1.0.0; le definizioni di processo e stato di BIP 3; il design di attivazione di BIP 9; BIP 141, 341 e 342; la documentazione della policy sui data-carrier di Bitcoin Core; la documentazione sulla potatura di Bitcoin Core; e il riferimento alla ricompensa di blocco per gli sviluppatori di Bitcoin. (GitHub
