Dura verdade re: Luke hardfork drama: Não acho que haja nada de errado em construir um cliente _alternativo_ que sincroniza com a ponta de cadeia mais recente e pesada por meio do ZK, mesmo que isso signifique não baixar todo o conteúdo do bloco ... nem mesmo se houver um consórcio centralizado (multisig) que tenha controle sobre quais partes da cadeia são validadas por meio do ZK e as partes são validadas normalmente Mesmo que isso signifique que o _reference client_ (Core) ficaria preso sincronizando a cadeia se os ÚNICOS dados disponíveis em toda a rede fossem os que meu cliente alternativo hospedava Seria um problema se o *cliente de referência* (ou o "cliente da grande maioria") adotasse isso ... porque se a grande maioria da rede o executasse, isso poderia levar a situações de divisão de cadeia Também pode ser um problema se o cliente alternativo que adota esse emparelhamento com outros nós da rede, fingindo ter os dados completos do blockchain, quando na realidade não tem, e tentar servir provas ZK irreconhecíveis em vez de dados tx reais para pares desavisados por algum motivo Isso seria equivalente a um ataque de eclipse, mas não temos motivos para acreditar que alguém tenha planejado ou planejaria algo do tipo Na realidade, esses nós (se honestos) provavelmente simplesmente anunciariam um bit de serviço adequado que comunica aos nós de sincronização (IBD) que eles não têm todos os dados Assim como os nós Core podados na rede fazem (bit de serviço: NODE_NETWORK_LIMITED == a maneira do seu nó dizer "Eu não tenho todo o histórico de blocos ... você tem que emparelhar com outra pessoa se quiser fazer uma sincronização completa") Não sou um especialista na mecânica de sincronização do Core, mas acredito que os nós do Core já priorizam as conexões que transmitem que eles têm os dados completos do blockchain e irão despejar / girar para fora de pares limitados que não podem servir ao histórico completo Em geral, é sempre responsabilidade do cliente Core fazer a rotação de pares e encontrar conexões honestas na rede, para ter resistência contra situações de eclipse intencionalmente contraditórias e não intencionalmente adversárias na rede 🔸🔸🔸🔸 Agora, onde as coisas ficam complicadas é se eu não apenas lancei/construí/planejei lançar esse cliente alternativo, mas também publicamente fomentado ao medo sobre como o cliente de referência *** garante a morte do Bitcoin*** e eu também estava explorando caminhos legais para desincentivar nós ou pools de mineração de executar o Core. Não sei muito sobre esta última parte (legal), então não vou falar sobre ela. De qualquer forma, essa é a essência do motivo pelo qual algumas pessoas dirão que o que Luke estava planejando não era um hardfork de censura (e apenas um cliente de hardfork em uma definição técnica estrita porque pode desencadear uma divisão em cadeia sob condições improváveis), enquanto outros observam o contexto legal / fomentador do medo que abrange um quadro bastante nefasto. Fim.

e *quais* partes são validadas normalmente... erro de digitação no primeiro parágrafo

No caso do Knots, o acima pode muito bem ser pretendido como um recurso opcional, não algo que todos os nós fariam por padrão.