Compact Block Filters são pequenos resumos dos blocos do Bitcoin. A carteira os baixa e verifica no próprio aparelho quais blocos podem conter seus pagamentos. Só depois pede esses blocos completos. Isso economiza dados e revela menos sobre a busca. Uma correspondência no filtro, porém, não comprova um pagamento nem substitui a verificação completa das regras do Bitcoin.
Anna espera um pagamento na carteira do celular. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Blocos são conjuntos de transações, mas o telefone não precisa baixar todos integralmente. Primeiro pode consultar pequenos filtros, como quem procura uma página no índice de um livro. Para o mesmo bloco e tipo de filtro, todos recebem o mesmo resumo; a seleção do que importa a Anna acontece no aparelho dela. Os documentos técnicos BIP 157 e BIP 158 dividem o trabalho: o primeiro define como obter e conferir filtros; o segundo, seu conteúdo e construção. A carteira começa verificando os cabeçalhos dos blocos, os registros básicos que os ligam em uma cadeia. Depois obtém os dados de conferência dos filtros e os próprios filtros. Ao encontrar uma correspondência, baixa o bloco inteiro e procura a transação real. Compact Blocks, do BIP 152, tem nome parecido, mas resolve outro problema: retransmitir novos blocos rapidamente entre nós. Um nó é um programa que verifica transações e blocos e se comunica com outros participantes da rede. [1] [2] [5] [6]
Uma transação Bitcoin cria saídas: valores com condições para serem gastos depois. O código dessas condições se chama scriptPubKey. Uma entrada de uma nova transação aponta para uma saída anterior que está sendo gasta. Por isso o filtro basic, identificado por 0x00, inclui tanto os scripts das novas saídas quanto os das saídas anteriores gastas no bloco. Anna pode procurar recebimentos e gastos. Ficam de fora scripts novos iniciados por OP_RETURN, instrução que torna a saída impossível de gastar. Também fica de fora a entrada especial da transação coinbase, que atribui a recompensa ao minerador sem gastar uma saída anterior. Elementos vazios são omitidos e repetições contam uma única vez. Não é uma lista de todos os identificadores de transação txid, endereços em texto ou dados witness, como assinaturas. A construção correta exige também as saídas anteriores gastas pelas transações, não apenas o bloco novo. [2]
Um servidor poderia enviar a Anna um resumo que omite seu pagamento de propósito. A carteira verifica, portanto, também os vínculos com filtros anteriores. Um hash é uma curta impressão digital de dados. Aplicar SHA-256 duas vezes ao filtro armazenado produz seu double-SHA256. Essa impressão é concatenada com o cabeçalho do filtro anterior e passa pelo mesmo cálculo, formando o próximo cabeçalho. Alterar um filtro antigo muda assim os dados de conferência seguintes. Mas o cabeçalho do bloco, protegido pela mineração, não contém um hash dessa cadeia auxiliar de filtros. Se todos os servidores entregarem a mesma cadeia falsa, as impressões ainda poderão se encaixar perfeitamente. Coerência matemática, sozinha, não prova que o resumo corresponde ao bloco verdadeiro. [1]
BIP 157 recomenda por isso conexões com vários nós independentes, chamados peers nessa troca. Uma conexão segura com um nó confiável, como o próprio, é outra opção. Diante de cadeias de filtros contraditórias, a carteira encontra a primeira divergência e pode reconstruir o filtro correto com o bloco e as saídas anteriores necessárias. A garantia de identificar os filtros certos pressupõe pelo menos um peer honesto; várias conexões com o mesmo atacante não atendem a essa condição. A cadeia também pode mudar: numa reorganização, os nós substituem parte de sua ponta por um ramo com mais trabalho comprovado acumulado. A carteira precisa seguir os filtros desse ramo e reavaliar os pagamentos afetados. Uma confirmação já encontrada continua dependendo da cadeia aceita pela rede. [1] [2]
No método anterior do BIP 37, a carteira enviava ao servidor um filtro próprio das informações que queria acompanhar. Compact Block Filters invertem o processo: a carteira baixa dados gerais e faz a seleção pessoal localmente. Isso reduz a exposição dos scripts acompanhados. O fornecedor ainda vê quais blocos completos Anna pede depois e pode ligar os pedidos ao seu endereço IP, o endereço de rede da conexão. Visitas repetidas podem revelar outros padrões. BIP 157 recomenda escolher aleatoriamente as fontes de blocos completos entre os nós aos quais a carteira abriu conexões. Bloco e filtro podem vir de nós diferentes. A privacidade melhora, mas não há garantia de anonimato. [1]
Filtros descrevem blocos já incluídos na cadeia. Não cobrem o Mempool atual: as transações ainda não confirmadas que determinado nó guarda para retransmitir ou minerar. Uma correspondência também não prova que Anna possui a chave necessária para gastar os fundos encontrados. Uma chave privada é um valor numérico secreto que a carteira usa para criar uma assinatura digital que autoriza um gasto. A carteira precisa verificar a transação real e sua inclusão no bloco. Mesmo assim, um cliente leve não verifica cada transação de cada bloco segundo todas as regras, como um Full Node. A economia de recursos envolve uma diferença real de segurança. Disponibilidade é outra questão: um Pruned Node pode apagar blocos antigos depois de verificá-los e conservar os filtros. Anna obtém então o resumo, mas precisa buscar o bloco completo em outro lugar. A poda, por si só, não significa abandonar a verificação completa das regras. [1] [5]
O tamanho reduzido tem uma contrapartida: o filtro pode responder “talvez sim” quando o elemento nem está no bloco. É um falso positivo. Anna baixa então um bloco sem necessidade, mas a carteira não encontra o suposto pagamento e não deve contabilizá-lo. Um filtro correto não perde um elemento que suas regras realmente incluem; essa propriedade não torna confiáveis dados inventados por um servidor desonesto. Tecnicamente, SipHash-2-4 transforma elementos em números num intervalo de tamanho N × M, em que N é a quantidade de elementos. Os números são ordenados e suas diferenças armazenadas de forma compacta pela codificação Golomb-Rice. P=19 controla a codificação; M=784931 influencia correspondências aleatórias, cuja probabilidade para uma consulta fora do conjunto é aproximadamente 1/M. Byte é uma unidade comum para medir dados. A chave de SipHash usa os primeiros 16 bytes do hash do bloco em ordem little-endian, dos bytes menos significativos para os mais significativos. Essa não é uma chave secreta da carteira. Aqui, SipHash transforma os elementos em números para o filtro, sem criptografá-los. O filtro armazenado começa com N em CompactSize, formato para inteiros não negativos. [2]
Na revisão de 2026-10-17, ambos os documentos têm status Deployed: o protocolo foi implantado, o que não significa suporte em toda carteira. Este exemplo de configuração se refere especificamente ao Bitcoin Core 29.0. -blockfilterindex cria o índice local. -peerblockfilters ativa o serviço a outros nós e exige um índice basic; NODE_COMPACT_FILTERS anuncia essa capacidade. A interface de programação RPC oferece getblockfilter, que devolve os campos filter e header de um bloco escolhido. Uma consulta RPC funcionando não comprova, sozinha, que outros nós conseguem obter filtros pela rede. Para quem lê a especificação: getcfilters/cfilter transmite filtros, getcfheaders/cfheaders os dados de encadeamento, e getcfcheckpt/cfcheckpt os pontos de conferência dessa cadeia auxiliar. São nomes de mensagens de rede, não comandos que o usuário de uma carteira móvel precisa digitar. [3] [4]
Para ter uma visão mais completa, leia este verbete junto com Neutrino, Full Node, Pruned Node, Privacidade no Bitcoin, Compact Blocks, Mempool. Também há referências a este verbete em Compact Block Filters, Neutrino.