Harde waarheid over de Luke hardfork drama: Ik denk niet dat er iets mis is met het bouwen van een _alternatieve_ client die synchroniseert met de laatste, zwaarste chaintip door middel van ZK, zelfs als dat betekent dat niet alle blokinhoud gedownload wordt... zelfs niet als er een gecentraliseerd consortium (multisig) is dat controle heeft over welke delen van de keten gevalideerd worden via ZK en welke delen normaal gevalideerd worden. Zelfs als dat betekent dat de _referentieclient_ (Core) vast komt te zitten met het synchroniseren van de keten als de ENIGE data die beschikbaar is in het hele netwerk datgene is wat mijn alternatieve client host. Het ZOU een probleem zijn als de *referentieclient* (of de "overgrote meerderheid-client") dit zou aannemen... want als de overgrote meerderheid van het netwerk het zou draaien, zou dat kunnen leiden tot chainsplit-situaties. Het zou ook een probleem kunnen zijn als de alternatieve client die dit aanneemt verbinding maakt met andere knooppunten in het netwerk, zich voordoet alsof ze de volledige blockchain-data hebben, terwijl dat in werkelijkheid niet zo is, en probeert onherkenbare ZK-bewijzen te serveren in plaats van daadwerkelijke tx-data aan nietsvermoedende peers om een of andere reden. Dat zou gelijkstaan aan een eclipse-aanval, maar we hebben geen reden om te geloven dat iemand iets dergelijks heeft gepland of zou plannen. In werkelijkheid zouden zulke knooppunten (als ze eerlijk zijn) waarschijnlijk gewoon een juiste servicebit adverteren die communiceert met knooppunten die synchroniseren (IBD) dat ze niet alle data hebben. Net zoals geprune Core-knooppunten op het netwerk doen (servicebit: NODE_NETWORK_LIMITED == de manier waarop jouw knooppunt zegt "Ik heb de hele blokgeschiedenis niet... je moet met iemand anders verbinden als je een volledige synchronisatie wilt"). Ik ben geen expert op het gebied van de synchronisatiemechanica van Core, maar ik geloof dat Core-knooppunten al prioriteit geven aan verbindingen die uitzenden dat ze de volledige blockchain-data hebben, en zullen uit beperkte peers die de volledige geschiedenis niet kunnen serveren, verwijderen/roteren. Over het algemeen is het altijd de verantwoordelijkheid van de Core-client om peers te roteren en eerlijke verbindingen op het netwerk te vinden, om weerstand te bieden tegen opzettelijk vijandige, evenals onopzettelijk vijandige situaties die lijken op eclipse-aanvallen op het netwerk. 🔸🔸🔸🔸 Nu, waar het ingewikkeld wordt, is als ik niet alleen deze alternatieve client zou uitbrengen/bouwen/plannen om uit te brengen, maar ook publiekelijk angst zou zaaien over hoe de referentieclient ***de dood van Bitcoin garandeert*** en ik ook juridische paden zou verkennen om knooppunten of mining pools te ontmoedigen om Core te draaien. Ik weet niet veel over dit laatste (juridische) deel, dus daar zal ik niet over spreken. Hoe dan ook, dat is de essentie van waarom sommige mensen zullen zeggen dat wat Luke van plan was geen censuur hardfork was (en alleen een hardforking client in een strikte technische definitie omdat het een chainsplit kan triggeren onder onwaarschijnlijke omstandigheden), terwijl anderen de angstzaaiende/juridische context observeren die een vrij kwaadwillend beeld schetst. Einde.

en *welke* delen normaal worden gevalideerd... typefout in de eerste alinea

In het geval van Knots zou het bovenstaande heel goed bedoeld kunnen zijn als een opt-in functie, niet iets dat alle knooppunten standaard zouden doen.