Compact Block Filters são índices probabilísticos de blocos para clientes leves. A carteira baixa um filtro e testa seus scripts localmente, em vez de enviar um filtro pessoal de endereços ao servidor como em BIP 37. BIP 157 e BIP 158 estão Deployed na revisão, mas não substituem a validação completa do consenso.
BIP 157 define getcfilters/cfilter, getcfheaders/cfheaders e getcfcheckpt/cfcheckpt. BIP 158 especifica o filtro basic tipo 0x00. O cliente sincroniza primeiro cabeçalhos de blocos, depois cabeçalhos de filtros e filtros; ao encontrar correspondência baixa o bloco e procura transações reais. Isso difere de Compact Blocks do BIP 152 para retransmissão rápida de blocos. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
O filtro contém scriptPubKey de saídas novas, exceto scripts iniciados por OP_RETURN, e scripts de saídas anteriores gastas pelas entradas, excluindo a entrada coinbase. Itens vazios são omitidos e os itens formam um conjunto. Não é índice de todos os txid, textos de endereços ou dados witness; a construção também exige as saídas anteriores gastas. [BIP 158 — Compact Block Filters for Light Clients]
Valores SipHash-2-4 são mapeados para N × M, ordenados e suas diferenças codificadas com Golomb-Rice. Basic usa P=19 e M=784931; a chave são os primeiros 16 bytes do hash de bloco em little-endian. A serialização começa com N em CompactSize. Uma consulta externa ao conjunto pode dar falso positivo com probabilidade aproximada 1/M; um filtro correto não perde um item incluído. [BIP 158 — Compact Block Filters for Light Clients]
O hash do filtro é double-SHA256 de sua serialização. Seu cabeçalho é double-SHA256 desse hash concatenado com o cabeçalho de filtro anterior. Isso cria ligações verificáveis, mas o compromisso não está no cabeçalho de bloco do consenso. Só calcular hashes não revela uma cadeia falsa coerente enviada por todos os pares conectados. [BIP 157 — Client Side Block Filtering]
BIP 157 recomenda vários pares independentes, salvo conexão segura com um par confiável. Em divergências o cliente encontra a primeira diferença e verifica o filtro contra o bloco e os dados necessários de saídas anteriores. A garantia de filtros corretos pressupõe pelo menos um par honesto. Após reorganização, os filtros devem seguir o novo ramo e o estado pertinente da carteira deve ser recalculado. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
A comparação local não revela ao par os scripts procurados. Pedidos posteriores de blocos completos ainda revelam interesse e podem ser correlacionados com IP ou consultas repetidas. BIP 157 recomenda selecionar fontes de blocos aleatoriamente entre pares de saída; a fonte não precisa servir filtros. Isso não garante anonimato. [BIP 157 — Client Side Block Filtering]
Um filtro diz respeito a um bloco confirmado, não ao Mempool atual. Uma correspondência não prova pagamento nem autorização de gasto; transações e validações necessárias determinam isso. Um nó pode manter filtros após podar blocos, mas então talvez não forneça um bloco completo antigo. A economia de clientes leves não substitui o modelo de segurança de Full Node. [BIP 157 — Client Side Block Filtering]
No Bitcoin Core 29.0, -blockfilterindex cria o índice; -peerblockfilters habilita o serviço aos pares e exige índice basic. NODE_COMPACT_FILTERS sinaliza esse serviço. O RPC getblockfilter retorna filter e header para o bloco escolhido. Ter RPC ou índice não significa, por si só, servir filtros por P2P; este verbete não altera a configuração do nó. [Bitcoin Core 29.0 — getblockfilter RPC] [Bitcoin Core 29.0 — Filter service configuration]
Para ter uma visão mais completa, leia este verbete junto com Neutrino, Full Node, Pruned node, Privacidade no Bitcoin, Compact block relay. Também há referências a este verbete em Compact Block Filters, Neutrino.