Verità difficile riguardo al dramma del hardfork di Luke: Non penso ci sia nulla di sbagliato nel costruire un client _alternativo_ che si sincronizza con l'ultimo, più pesante chaintip tramite ZK, anche se significa non scaricare tutti i contenuti dei blocchi... nemmeno se c'è un consorzio centralizzato (multisig) che ha il controllo su quali porzioni della catena vengono validate tramite ZK e quali porzioni vengono validate normalmente. Sarebbe un problema se il *client di riferimento* (Core) rimanesse bloccato nella sincronizzazione della catena se l'UNICO dato disponibile nell'intera rete fosse quello ospitato dal mio client alternativo. SAREBBE un problema se il *client di riferimento* (o il "client della vasta maggioranza") adottasse questo... perché se la vasta maggioranza della rete lo eseguisse, potrebbe portare a situazioni di chainsplit. Potrebbe anche essere un problema se il client alternativo che adotta questo si collega con altri nodi nella rete, fingendo di avere i dati completi della blockchain, quando in realtà non li ha, e cercasse di servire prove ZK non riconoscibili al posto dei dati delle transazioni reali a peer ignari per qualche motivo. Questo sarebbe equivalente a un attacco di eclissi, ma non abbiamo motivo di credere che qualcuno abbia pianificato o pianificherebbe qualcosa del genere. In realtà, tali nodi (se onesti) probabilmente pubblicizzerebbero semplicemente un bit di servizio appropriato che comunica ai nodi in sincronizzazione (IBD) che non hanno tutti i dati. Proprio come fanno i nodi Core potati sulla rete (bit di servizio: NODE_NETWORK_LIMITED == il modo in cui il tuo nodo dice "Non ho l'intera storia dei blocchi... devi collegarti con qualcun altro se vuoi fare una sincronizzazione completa"). Non sono un esperto della meccanica di sincronizzazione di Core, ma credo che i nodi Core già diano priorità alle connessioni che trasmettono di avere i dati completi della blockchain e espelleranno/ruoteranno fuori dai peer limitati che non possono fornire l'intera storia. In generale, è sempre responsabilità del client Core ruotare i peer e trovare connessioni oneste sulla rete, per avere resistenza contro situazioni di attacco di eclissi intenzionalmente avversariali così come contro situazioni di attacco di eclissi involontariamente avversariali sulla rete. 🔸🔸🔸🔸 Ora, dove le cose si complicano è se non solo rilasciassi/costruissi/pianificassi di rilasciare questo client alternativo, ma anche se facessi pubblicamente terrorismo psicologico su come il client di riferimento ***garantisce la morte di Bitcoin*** e stessi anche esplorando percorsi legali per disincentivare i nodi o i pool di mining dall'eseguire Core. Non so molto su quest'ultima parte (legale), quindi non ne parlerò. Comunque, questo è il succo del perché alcune persone diranno che ciò che Luke stava pianificando non era un hardfork di censura (e solo un client di hardfork in una rigorosa definizione tecnica perché può innescare un chainsplit in condizioni improbabili), mentre altri osservano il contesto di terrorismo psicologico/legale che dipinge un quadro piuttosto nefasto.

Le guerre dei filtri continueranno finché Giacomo e Udi non si saranno ancora riappacificati e diventeranno di nuovo amici.