Compact Block Filters son índices probabilísticos de bloques para clientes ligeros. La cartera descarga el filtro y prueba sus scripts localmente, en vez de enviar un filtro personal de direcciones al servidor como en BIP 37. BIP 157 y BIP 158 están Deployed en la revisión, pero no sustituyen la validación completa del consenso.
BIP 157 define getcfilters/cfilter, getcfheaders/cfheaders y getcfcheckpt/cfcheckpt. BIP 158 especifica el filtro basic de tipo 0x00. El cliente sincroniza primero cabeceras de bloque, luego cabeceras de filtro y filtros; ante una coincidencia descarga el bloque y localiza transacciones reales. Se distingue de Compact Blocks de BIP 152 para difusión rápida de bloques. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
El filtro contiene scriptPubKey de salidas nuevas salvo scripts que comiencen por OP_RETURN, y scripts de salidas anteriores gastadas por las entradas, excluyendo la entrada coinbase. Se omiten elementos vacíos y se usa un conjunto. No indexa todos los txid, textos de direcciones o datos witness; construirlo requiere también las salidas anteriores gastadas. [BIP 158 — Compact Block Filters for Light Clients]
Los valores SipHash-2-4 se mapean al rango N × M, se ordenan y sus diferencias se codifican con Golomb-Rice. Basic usa P=19 y M=784931; la clave son los primeros 16 bytes del hash de bloque en forma little-endian. La serialización empieza con N en CompactSize. Una consulta ajena al conjunto puede dar falso positivo con probabilidad aproximada 1/M; un filtro correcto no omite un elemento incluido. [BIP 158 — Compact Block Filters for Light Clients]
El hash del filtro es double-SHA256 de su serialización. Su cabecera es double-SHA256 de ese hash concatenado con la cabecera de filtro anterior. Crea vínculos verificables, pero el compromiso no está en la cabecera de bloque del consenso. El hash por sí solo no descubre una cadena falsa coherente proporcionada por todos los pares conectados. [BIP 157 — Client Side Block Filtering]
BIP 157 recomienda varios pares independientes salvo conexión segura a un par confiable. Ante discrepancias se localiza la primera diferencia y se verifica el filtro contra el bloque y los datos necesarios de salidas anteriores. La garantía de filtros correctos supone al menos un par honesto. Tras una reorganización los filtros deben seguir la nueva rama y debe recalcularse el estado pertinente de la cartera. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Las pruebas locales no revelan al par los scripts buscados. Las solicitudes posteriores de bloques completos sí revelan interés y pueden correlacionarse con direcciones IP o consultas repetidas. BIP 157 recomienda elegir aleatoriamente fuentes de bloques entre pares salientes; la fuente no necesita servir filtros. No garantiza anonimato. [BIP 157 — Client Side Block Filtering]
El filtro corresponde a un bloque confirmado, no al Mempool actual. Una coincidencia no demuestra pago ni autorización de gasto; lo determinan las transacciones y validaciones necesarias. Un nodo puede conservar filtros después de podar bloques, pero entonces quizá no sirva un bloque completo antiguo. El ahorro del cliente ligero no sustituye el modelo de seguridad de Full Node. [BIP 157 — Client Side Block Filtering]
En Bitcoin Core 29.0, -blockfilterindex crea el índice; -peerblockfilters habilita el servicio a pares y requiere el índice basic. NODE_COMPACT_FILTERS anuncia ese servicio. El RPC getblockfilter devuelve filter y header para el bloque elegido. Tener RPC o índice no implica servir filtros por P2P; esta entrada no cambia la configuración del nodo. [Bitcoin Core 29.0 — getblockfilter RPC] [Bitcoin Core 29.0 — Filter service configuration]
Para obtener la imagen más completa, lee esta entrada junto con Neutrino, Full Node, Nodo podado, Privacidad en Bitcoin, Retransmisión compacta. También enlazan con esta entrada Compact Block Filters, Neutrino.