MSG_FILTERED_WITNESS_BLOCK

MSG_FILTERED_WITNESS_BLOCK é o código de inventário 0x40000003, reservado quando as regras de pares do segwit foram escritas em 2016 e nunca recebeu uma implementação. O Bitcoin Core o traz como uma entrada de enum com um comentário que registra exatamente isso. O recurso de carteira leve que ele teria ampliado, a filtragem de Bloom do BIP37, foi desativado por padrão no Bitcoin Core 0.19.0, o que só importa para você se a carteira do seu celular ainda depende dele.

Como funciona

Status: reservado e nunca implementado. O BIP144 deu nome ao tipo; o Bitcoin Core o traz como uma entrada de enum em src/protocol.h com um comentário que registra que nenhum manipulador existe. A filtragem do BIP37 a que ele teria servido está desativada por padrão desde o Bitcoin Core 0.19.0, em novembro de 2019, e os filtros compactos de bloco do BIP157 e do BIP158 são o substituto.

Entender a lacuna exige entender o que era um bloco filtrado. Um cliente leve que usa BIP37 envia uma mensagem filterload descrevendo, de forma aproximada, os endereços que lhe interessam. Em seguida, solicita o tipo de inventário 3, MSG_FILTERED_BLOCK, e o nó que o atende responde com uma mensagem merkleblock: o cabeçalho de bloco de 80 bytes, uma contagem de transações, um ramo de Merkle parcial e um campo de bits que indica por onde percorrer a árvore. As transações correspondentes chegam depois como mensagens separadas. O cliente verifica que cada uma realmente pende da raiz de Merkle do cabeçalho, e faz isso usando apenas os txids.

As testemunhas nunca entraram nessa aritmética. Como a raiz de Merkle é construída a partir dos txids, um cliente leve pode provar a inclusão sem uma única assinatura, então as transações seguintes eram enviadas sem os dados de testemunha. O tipo reservado 3 com o sinalizador de testemunha acrescentado, 0x40000003, teria permitido a um cliente pedir essas transações completas. Ninguém o implementou, porque ninguém que produzia carteiras leves queria mais BIP37.

A razão é a privacidade, não o esforço. O filtro que um cliente envia diz ao nó que o atende, de forma aproximada, quais endereços lhe pertencem, e pesquisas de meados da década de 2010 mostraram que esses filtros vazavam muito mais do que se pretendia. A resposta do Bitcoin Core foi parar de atendê-los por padrão em vez de consertar o desenho. O BIP158 inverte o fluxo: o nó constrói um pequeno filtro com codificação Golomb por bloco, calibrado para uma taxa de falsos positivos de um em 784.931, e o publica. O cliente baixa os filtros, testa-os localmente e só busca um bloco inteiro quando há uma coincidência, de modo que o servidor não fica sabendo quais endereços interessavam.

Onde você o encontra

Em quase nenhum lugar, que é a resposta honesta para quem encontra MSG_FILTERED_WITNESS_BLOCK em uma tabela de referência.

Faça um grep no Bitcoin Core pela constante e você encontra um único membro de enum. Implementações alternativas, como a btcd, espelham o nome em seus pacotes de rede por completude, de novo sem nenhum comportamento por trás. Nenhuma carteira jamais o enviou.

Onde o tema toca um comprador é em como uma carteira móvel obtém seus dados. Se uma carteira se descreve como SPV e se conecta a nós públicos aleatórios com filtros de Bloom, ela está usando um mecanismo que a implementação de referência parou de atender por padrão anos atrás, e está contando a esses nós algo sobre seus endereços. As carteiras construídas sobre filtros compactos de bloco, o desenho por trás do Neutrino, do lnd, pedem muito menos. Uma carteira apontada para o servidor do próprio fornecedor é a terceira opção, e a mais comum: rápida, privada em relação a desconhecidos e totalmente visível para o fornecedor.

MSG_FILTERED_WITNESS_BLOCK vs bloco de Merkle

Um bloco de Merkle é a resposta; MSG_FILTERED_WITNESS_BLOCK é uma solicitação que nunca foi ligada para produzir um. A mensagem merkleblock é uma estrutura real e implementada que prova que um conjunto de transações pertence a um bloco sem enviar o bloco. A variante reservada com testemunha só teria mudado o que vinha depois dessa prova, ou seja, se as transações correspondentes chegavam com suas assinaturas. Como as provas de inclusão funcionam com base nos txids, o recurso ausente não custou nada a ninguém.