Tvrdá pravda re: Luke hardfork drama: Nemyslím si, že je něco špatného na vytvoření _alternativního_ klienta, který se synchronizuje s nejnovějším a nejtěžším chaintipem pomocí ZK, i když to znamená nestahovat veškerý obsah bloku... a to ani v případě, že existuje centralizované konsorcium (multisig), které má kontrolu nad tím, které části řetězce jsou validovány prostřednictvím ZK a části jsou validovány normálně I když to znamená, že _reference client_ (Core) by se zasekl při synchronizaci řetězce, pokud by JEDINÁ data dostupná v celé síti byla ta, která hostoval můj alternativní klient Byl by problém, kdyby to *referenční klient* (nebo "klient s drtivou většinou") přijal... Protože pokud by to provozovala drtivá většina sítě, mohlo by to vést k situacím rozdělení chainu Problém by mohl být také v případě, že alternativní klient, který to přijme, se srovnává s ostatními uzly v síti a vytváří, jako by měl úplná data blockchainu, i když ve skutečnosti je nemá, a z nějakého důvodu se pokusil nic netušícím kolegům poskytnout nerozpoznatelné důkazy ZK místo skutečných vysílacích dat To by se rovnalo útoku na zatmění, ale nemáme žádný důvod věřit, že někdo něco takového plánoval nebo plánoval Ve skutečnosti by takové uzly (pokud by byly upřímné) jednoduše inzerovaly správný servisní bit, který komunikuje se synchronizací uzlů (IBD), že nemají všechna data Stejně jako to dělají ořezané uzly Core v síti (service bit: NODE_NETWORK_LIMITED == způsob, jakým váš uzel říká "Nemám celou historii bloků... pokud chcete provést úplnou synchronizaci, musíte se spojit s někým jiným") Nejsem odborník na mechaniku synchronizace Core, ale věřím, že uzly Core již upřednostňují připojení, která vysílají, že mají kompletní data blockchainu, a vyřadí je/rotují z omezených peerů, kteří nemohou obsluhovat celou historii Obecně platí, že je vždy odpovědností Core klienta střídat peery a hledat poctivé spojení v síti, mít odolnost proti úmyslně nepřátelským i neúmyslně nepřátelským situacím podobným zatmění v síti 🔸🔸🔸🔸 Věci se nyní stávají chlupatými, pokud jsem nejen vydal/postavil/plánoval vydat tohoto alternativního klienta, ale také jsem veřejně šířil strach z toho, jak referenční klient ***zaručuje smrt Bitcoinu *** a také jsem zkoumal právní cesty, jak odradit uzly nebo těžební pooly od provozu Core. O této poslední (právní) části toho moc nevím, takže o ní nebudu mluvit. Každopádně to je podstata toho, proč někteří lidé řeknou, že to, co Luke plánoval, nebyl cenzurní hardfork (a pouze hardforkující klient v přísné technické definici, protože to může za nepravděpodobných podmínek spustit chainsplit), zatímco jiní si všímají strachu vyvolávajícího/právního kontextu, který všeobjímajícím způsobem vykresluje poněkud hanebný obrázek. Konec.

a *které* části jsou normálně validovány... překlep v prvním odstavci

V případě Knots by výše uvedené mohlo být velmi dobře zamýšleno jako volitelná funkce, ne jako něco, co by všechny uzly dělaly ve výchozím nastavení.