Discussione sui Fork Hard di Bitcoin
David Schwartz, CTO Emeritus di Ripple, ha recentemente partecipato a una discussione su X, dove ha spiegato la logica alla base dei fork hard di Bitcoin. Un utente di X ha sollevato dubbi sul valore di un nuovo fork PoW, citando Bitcoin Cash e la più recente proposta BIP-110.
Problemi di Governance nei Fork
Sebbene i fork possano affrontare problemi “superficiali”, come l’eccesso o la scarsità di spam in una rete, ereditano comunque il problema di governance sottostante, ha osservato l’utente.
“Se credi che la vecchia catena sia stata catturata, come può aiutare creare un nuovo fork PoW? Certo, avrà la caratteristica che desideravi, ma a un certo punto, se la tua nuova catena diventa molto popolare, verrà catturata di nuovo.”
La Prospettiva di Schwartz sui Fork PoW
La prospettiva di Schwartz sui fork PoW è piuttosto diversa: egli sostiene che questi offrono ai partecipanti la possibilità di scegliere tra set di regole concorrenti. Il fine del fork è consentire a tutti di ottenere ciò che vogliono, scegliendo quale lato del fork vogliono supportare. Se le persone sul lato “perdente” si spostano verso il lato “vincente”, è perché si rendono conto che le regole del lato vincente producono risultati più favorevoli.
“Perché altro?”
Questo implica che se i partecipanti non sono d’accordo con le regole di una rete esistente, un fork può offrire loro un’alternativa. Se quell’alternativa diventa più attraente, gli utenti possono decidere di migrare verso di essa.
Il Caso di BIP-110
Sabato scorso, una nuova catena minoritaria, creata quando i sostenitori di BIP-110 si sono distaccati da Bitcoin, è durata solo due blocchi. BIP-110, formalmente noto come Reduced Data Temporary Softfork, è stato concepito dallo sviluppatore pseudonimo Dathon Ohm, con il contributo di Luke Dashjr, creatore del software per nodi Bitcoin Knots.
Questa proposta prevedeva una restrizione a livello di consenso di un anno sui dati arbitrari nelle transazioni Bitcoin, inclusi gli Ordinals (la risposta di Bitcoin agli NFT), BRC-20 e Runes (entrambi standard di token fungibili), e OP_RETURN sovradimensionati. La proposta conteneva sette regole che limitavano la maggior parte degli output a 34 byte, OP_RETURN a 83 byte e i push di dati a 256 byte, oltre a restrizioni sugli allegati Taproot e sui blocchi di controllo.
