A mineração é centralizada. A preocupação em torno de conteúdo questionável é atendida com apelos à descentralização da mineração - ou seja, uma rede Bitcoin que não existe. Até agora, o que já foi "tecnicamente possível" com o armazenamento de coisas desagradáveis na cadeia não era. 1. "O" mempool foi protegido porque todos filtrariam um OP_RETURN doente de 100kb junto com *todos* os OP_RETURNs maiores que 83 bytes. 2. A blockchain foi protegida porque os poucos mineradores que existem no mundo rejeitariam conteúdo malicioso enviado diretamente. Isso deixou uma opção para sabotagem: um atacante minerando um OP_RETURN de CSAM diretamente na cadeia. Referir-se a algo tão impraticável quanto isso como "tecnicamente possível" é totalmente frívolo e teria sido risível se tivesse acontecido. Um pool "Desconhecido" encontra um bloco que contém um gigantesco MP4 de 1MB de algo horrível? Sabotagem óbvia que universalmente evitaríamos e estou confiante de que seríamos capazes de resolver isso depois do fato. Agora, no entanto, a situação mudou. A F2Pool solicita esse tipo de conteúdo diretamente da rede p2p e nós do Libre Relay, juntamente com os candidatos a lançamento do Core 30, estão relaying isso de bom grado. Agora existe uma rede p2p anônima para esse ataque que é de acesso livre e há um minerador que irá atendê-la. A combinação do acima, na prática, reduz o custo de seis dígitos ($$$,$$$) para três ($$$) e torna possível fazê-lo anonimamente. Mas, mais importante, o mecanismo do ataque faz com que o conteúdo resultante pareça ter sido endossado pela rede a nível de política, em vez de resultar de uma contorna que explora regras de consenso rudimentares. Se você ainda não consegue entender a importância disso, então você deve simplesmente não estar ciente das mudanças que o Bitcoin sofreu com toda a manipulação maliciosa recente e o desejo absoluto de eliminar o Bitcoin. Novamente: A rede p2p se protegeu de ataques devido a políticas de mempool padrão sensatas, enquanto a blockchain tem sido inacessível para atacantes devido a pools que não querem ser responsabilizados por blocos contendo dados maliciosos. Esses fatores tecnicamente contornáveis agora desapareceram e não há limitação prática ao ataque além de limpar algumas moedas e pagar algumas centenas de dólares em taxas de transação para inserir conteúdo inaceitável na cadeia. Se a rede não vai se proteger de atividades maliciosas e válidas para o consenso, então a única opção restante é mudar o consenso e fazer um soft fork para limitar OP_RETURNs e talvez outros tipos conhecidos de transporte de dados. Essa ideia entrou na arena na lista de discussão na sexta-feira, vinda de alguém que é vocalmente contra os Knots (@PortlandHODL) e foi recebida positivamente pelos desenvolvedores do Core que responderam. Algumas embelezamentos foram oferecidos por Luke (adicionar tipos adicionais de transporte de dados) para os quais não houve tanta resposta. Sem o apoio da comunidade, um fork falha. É possível que, mesmo que os proponentes do Core 30 estejam de acordo em limitar esse tipo de conteúdo a nível de consenso, haja apoio da comunidade e, portanto, poderia ser o caminho a seguir. Eu não gosto disso porque abandona a mitigação de spam que ocorre a nível de política, que é onde pertence, mas o ambiente atual não nos está dando muito com o que trabalhar. Provavelmente é apropriado caracterizar o fork como uma defesa que nunca precisávamos contra um tipo específico de ataque versus a mitigação de spam em geral, que terá que continuar em paralelo. Fork?