Compact Block Filters

Anna espera un pago en la cartera de su teléfono. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Los bloques son conjuntos de transacciones, pero el móvil no necesita descargarlos todos completos. Primero puede recorrer pequeños filtros, como quien consulta el índice de un libro antes de abrir la página que le interesa. Todos reciben el mismo resumen para un bloque y un tipo de filtro determinados; la selección de lo relevante para Anna ocurre en su teléfono. Los documentos técnicos BIP 157 y BIP 158 se reparten el trabajo: el primero define cómo obtener y comprobar los filtros; el segundo, su contenido y construcción. La cartera verifica primero las cabeceras de los bloques, los datos básicos que los enlazan en una cadena, y después obtiene los datos de comprobación y los filtros. Si hay coincidencia, descarga el bloque completo y busca la transacción real. Compact Blocks, de BIP 152, tiene un nombre parecido, pero resuelve otro problema: transmitir rápidamente nuevos bloques entre nodos. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. [1] [2] [5] [6]

Una transacción Bitcoin crea salidas: importes con condiciones para gastarlos después. El código de esas condiciones se llama scriptPubKey. Una entrada de una nueva transacción señala una salida anterior que se está gastando. Por eso el filtro basic, identificado por 0x00, incluye tanto los scripts de las salidas nuevas como los de las salidas anteriores gastadas en el bloque. Anna puede buscar así entradas y salidas de fondos. Se excluyen los scripts nuevos que comienzan por OP_RETURN, una instrucción que hace que la salida no se pueda gastar. También se excluye la entrada especial de la transacción coinbase, que asigna la recompensa al minero sin gastar una salida anterior. Se omiten los elementos vacíos y los repetidos se cuentan una sola vez. No es una lista de todos los identificadores de transacción txid, direcciones en texto o datos witness, como las firmas. Para construirlo correctamente hacen falta también los datos de las salidas anteriores que se gastan, no solo el bloque nuevo. [2]

Un servidor podría enviar a Anna un resumen que omita su pago deliberadamente. Por eso la cartera comprueba también cómo enlaza cada filtro con los anteriores. Un hash es una huella digital breve de unos datos. Aplicar SHA-256 dos veces al filtro guardado produce su double-SHA256. Esa huella se une a la cabecera del filtro anterior y se vuelve a calcular del mismo modo para obtener la siguiente cabecera. Cambiar un filtro antiguo modifica así los datos de comprobación posteriores. Sin embargo, la cabecera del bloque protegida por la minería no contiene una huella de esta cadena auxiliar de filtros. Si todos los servidores entregan la misma cadena falsa, sus huellas pueden encajar perfectamente. La coherencia matemática no demuestra por sí sola que el resumen corresponda al bloque real. [1]

BIP 157 recomienda por ello conectarse a varios nodos independientes, llamados peers en esta comunicación. Otra opción es una conexión segura a un nodo de confianza, por ejemplo el propio. Si llegan cadenas de filtros contradictorias, la cartera localiza la primera discrepancia y puede reconstruir el filtro correcto con el bloque y las salidas anteriores necesarias. La garantía de identificar los filtros correctos presupone al menos un peer honesto; varias conexiones al mismo atacante no bastan. La cadena también puede cambiar: una reorganización sustituye parte de su extremo por una rama con más trabajo demostrado acumulado. La cartera debe seguir los filtros de esa rama y revisar los pagos afectados. Una confirmación ya encontrada sigue dependiendo de qué cadena acepta la red. [1] [2]

En el método anterior de BIP 37, la cartera enviaba al servidor su propio filtro sobre lo que quería vigilar. Compact Block Filters invierte el proceso: descarga datos generales y hace la selección personal en el dispositivo. Eso limita la información revelada sobre los scripts vigilados. Aun así, el proveedor ve qué bloques completos solicita Anna después y puede relacionarlos con su dirección IP, la dirección de red de su conexión. Las visitas repetidas pueden revelar más patrones. BIP 157 recomienda elegir al azar las fuentes de bloques completos entre los nodos a los que la cartera ha abierto conexiones. El bloque puede venir de un nodo distinto al del filtro. Mejora la privacidad, pero no garantiza el anonimato. [1]

Los filtros describen bloques ya incluidos en la cadena. No abarcan el Mempool actual: las transacciones sin confirmar que un nodo conserva para difundirlas o incluirlas en la minería. Una coincidencia tampoco demuestra que Anna tenga la clave para gastar los fondos encontrados. Una clave privada es un valor numérico secreto que la cartera utiliza para crear una firma digital que autoriza el gasto. La cartera debe comprobar la transacción real y su inclusión en el bloque. Aun así, un cliente ligero no verifica todas las transacciones de todos los bloques frente a todas las reglas como lo hace un Full Node. Ese es el compromiso de seguridad real a cambio del ahorro. La disponibilidad es otra cuestión: un Pruned Node puede borrar bloques antiguos después de verificarlos y conservar sus filtros. Anna consigue entonces el resumen, pero debe buscar el bloque completo en otro sitio. El borrado de bloques antiguos no implica por sí mismo dejar de verificar todas las reglas. [1] [5]

El tamaño reducido tiene una contrapartida: el filtro puede responder «quizá sí» aunque el elemento no esté en el bloque. Es un falso positivo. Anna descarga entonces un bloque innecesariamente, pero su cartera no encuentra el supuesto pago y no debe contabilizarlo. Un filtro correcto no omite un elemento que sus reglas incluyen; esto no ampara los datos inventados por un servidor deshonesto. En el detalle técnico, SipHash-2-4 transforma los elementos en números dentro de un rango de tamaño N × M, donde N es el número de elementos. Se ordenan los números y se guardan sus diferencias mediante la codificación Golomb-Rice. P=19 controla la codificación; M=784931 influye en las coincidencias aleatorias, cuya probabilidad para una consulta ajena al conjunto es aproximadamente 1/M. El byte es una unidad habitual para medir datos. La clave de SipHash son los primeros 16 bytes del hash del bloque en orden little-endian, con los bytes menos significativos primero. No es una clave secreta de la cartera. Aquí SipHash convierte los elementos en números para el filtro, no los cifra. El filtro guardado comienza con N codificado en CompactSize, un formato para enteros no negativos. [2]

En la revisión del 2026-10-17, ambos documentos tienen estado Deployed: el protocolo está desplegado, pero no necesariamente disponible en todas las carteras. Este ejemplo de configuración corresponde específicamente a Bitcoin Core 29.0. -blockfilterindex crea el índice local. Para servir filtros a otros nodos se necesita -peerblockfilters y un índice basic; NODE_COMPACT_FILTERS anuncia esa capacidad. La interfaz de programación RPC permite usar getblockfilter para obtener los campos filter y header de un bloque. Que funcione la RPC no demuestra por sí solo que otros nodos puedan obtener los filtros por la red. Para quien consulte la especificación: getcfilters/cfilter transmite filtros, getcfheaders/cfheaders sus datos de enlace y getcfcheckpt/cfcheckpt los puntos de comprobación de esta cadena auxiliar. Son nombres de mensajes de red, no órdenes que deba escribir quien usa una cartera móvil. [3] [4]