Tuff sanning re: Luke hardfork drama: Jag tror inte att det är något fel med att bygga en _alternativ_ klient som synkroniserar med den senaste, tyngsta kedjespetsen med hjälp av ZK, även om det innebär att du inte laddar ner allt blockinnehåll... inte ens om det finns ett centraliserat konsortium (multisig) som har kontroll över vilka delar av kedjan som valideras genom ZK och delar som valideras normalt Även om det innebär att _reference client_ (Core) skulle fastna i synkroniseringen av kedjan om den ENDA data som var tillgänglig i hela nätverket var den som min alternativa klient var värd för Det skulle vara ett problem om *referensklienten* (eller den "stora majoriteten-klienten") antog detta ... För om den stora majoriteten av nätverket skulle köra det skulle det kunna leda till kedjedelningssituationer Det kan också vara ett problem om den alternativa klienten som antar detta parar med andra noder i nätverket och utger sig för att ha full blockchain-data, när de i själva verket inte har det, och försökte servera oigenkännliga ZK-bevis i stället för faktiska tx-data till intet ont anande kamrater av någon anledning Det skulle vara liktydigt med en solförmörkelseattack, men vi har ingen anledning att tro att någon har planerat eller skulle planera något sådant I verkligheten skulle sådana noder (om de är ärliga) sannolikt helt enkelt annonsera en korrekt tjänstbit som kommunicerar till nodsynkronisering (IBD) att de inte har all data Precis som beskurna kärnnoder i nätverket gör (servicebit: NODE_NETWORK_LIMITED == din nods sätt att säga "Jag har inte hela blockhistoriken... du måste peera med någon annan om du vill göra en fullständig synkronisering") Jag är ingen expert på Cores synkroniseringsmekanik men jag tror att Core-noder redan prioriterar anslutningar som sänder att de har hela blockchain-data och kommer att avlägsna/rotera ut från begränsade peers som inte kan tjäna hela historiken I allmänhet är det alltid Core-klientens ansvar att rotera peers och hitta ärliga anslutningar i nätverket, att ha motståndskraft mot avsiktligt kontradiktoriska såväl som oavsiktligt kontradiktoriska eclipse-attackliknande situationer i nätverket 🔸🔸🔸🔸 Nu, där det blir hårigt är om jag inte bara släppte/byggde/planerade att släppa den här alternativa klienten, utan jag också offentligt skrämde om hur referensklienten ***garanterar Bitcoins död*** och jag utforskade också lagliga vägar för att avskräcka noder eller gruvpooler från att köra Core. Jag vet inte mycket om den senare (juridiska) delen så jag kommer inte att prata om den. Hur som helst, det är kontentan av varför vissa människor kommer att säga att det som Luke planerade inte var en censur hardfork (och bara en hardforking-klient i en strikt teknisk definition eftersom den kan utlösa en chainsplit under osannolika förhållanden), medan andra observerar den skrämselpropaganda/juridiska kontexten som allomfattande målar upp en ganska skändlig bild. Ände.

och *vilka* portioner som valideras normalt ... stavfel i första stycket

När det gäller Knots kan ovanstående mycket väl vara avsett som en opt-in-funktion, inte något som alla noder skulle göra som standard.