Tøff sannhet vedr.: Luke hardfork-drama: Jeg tror ikke det er noe galt med å bygge en _alternativ_ klient som synkroniserer til den nyeste, tyngste kjedespissen ved hjelp av ZK, selv om det betyr å ikke laste ned alt blokkinnholdet... ikke engang om det er et sentralisert konsortium (multisig) som har kontroll over hvilke deler av kjeden som valideres gjennom ZK og deler som valideres normalt Selv om det betyr at _reference client_ (Core) ville bli sittende fast med å synkronisere kjeden hvis de ENESTE dataene som var tilgjengelige i hele nettverket var det som min alternative klient var vert for Det VILLE vært et problem hvis *referanseklienten* (eller "det store flertallet-klienten") adopterte dette... For hvis det store flertallet av nettverket ville kjøre det, kunne det føre til kjedesplittede situasjoner Det kan også være et problem hvis den alternative klienten som tar i bruk disse peers med andre noder i nettverket, og utgir seg for å ha alle blokkjededataene, når de i virkeligheten ikke har det, og prøvde å servere ugjenkjennelige ZK-bevis i stedet for faktiske tx-data til intetanende peers av en eller annen grunn Det ville være ensbetydende med et formørkelsesangrep, men vi har ingen grunn til å tro at noen har planlagt eller vil planlegge noe slikt I virkeligheten vil slike noder (hvis de er ærlige) sannsynligvis ganske enkelt annonsere en skikkelig tjenestebit som kommuniserer til noder som synkroniserer (IBD) at de ikke har alle dataene Akkurat som beskjærte kjernenoder på nettverket gjør (servicebit: NODE_NETWORK_LIMITED == nodens måte å si "Jeg har ikke hele blokkeringshistorikken ... du må peer med noen andre hvis du vil gjøre en full synkronisering») Jeg er ikke ekspert på Cores synkroniseringsmekanikk, men jeg tror at Core-noder allerede prioriterer tilkoblinger som kringkaster at de har alle blokkjededataene, og vil kaste ut/rotere ut av begrensede jevnaldrende som ikke kan betjene hele historien Generelt er det alltid Core-klientens ansvar å rotere jevnaldrende og finne ærlige forbindelser på nettverket, å ha motstand mot tilsiktet-motstridende så vel som utilsiktet-motstridende formørkelsesangrep-lignende situasjoner på nettverket 🔸🔸🔸🔸 Nå, der ting blir hårete er hvis jeg ikke bare ga ut/bygde/planla å gi ut denne alternative klienten, men jeg også offentlig skremte hvordan referanseklienten ***garanterer Bitcoins død***, og jeg utforsket også juridiske veier for å avskrekke noder eller gruvebassenger fra å kjøre Core. Jeg vet ikke mye om denne sistnevnte (juridiske) delen, så jeg vil ikke snakke om den. Uansett, det er kjernen i hvorfor noen mennesker vil si at det Luke planla ikke var en sensur-hardfork (og bare en hardforking-klient i en streng teknisk definisjon fordi det kan utløse en kjedesplittelse under usannsynlige forhold), mens andre observerer den skremselspropaganda/juridiske konteksten som altomfattende maler et ganske ondsinnet bilde. Slutt.

og *hvilke* porsjoner valideres normalt ... skrivefeil i første avsnitt

Når det gjelder knuter, kan det ovennevnte godt være ment som en opt-in-funksjon, ikke noe alle noder ville gjort som standard.