Compact Block Filters

Anna abre la cartera del teléfono tras un tiempo sin usarla. La aplicación debe averiguar si alguien le ha pagado desde la última conexión o si se han gastado algunos de sus fondos. En vez de todas las transacciones, descarga pequeños filtros y los compara con las condiciones de las salidas que vigila. Una salida es la parte de una transacción que fija una cantidad y las reglas para gastarla después. Si hay coincidencia, solicita el bloque completo y busca la transacción real. No debe aumentar el saldo solo por el filtro. Este no es un extracto de cuenta ni una prueba de propiedad. Antes de buscar, el cliente sincroniza las cabeceras, datos breves que identifican los bloques, y las cabeceras enlazadas de los filtros. [1]

Con el antiguo enfoque BIP 37, el cliente enviaba a otro nodo un filtro construido con los datos que quería seguir. Aquí se invierte el sentido: el servidor entrega un filtro del bloque y Anna busca localmente. Para un mismo bloque y tipo de filtro, los clientes reciben el mismo contenido. No necesitan revelar directamente a cada servidor los scripts que buscan. Eso no proporciona anonimato: el otro nodo aún puede ver la dirección IP, los horarios y qué bloques completos solicita después la cartera. Repartir las descargas entre distintos nodos reduce la información reunida por uno solo, pero no elimina todas las correlaciones. [1]

Los Compact Block Filters seleccionan bloques que conviene examinar. Compact Blocks, definido en BIP 152, resuelve otro problema: ahorra datos al transmitir un bloque mediante identificadores cortos de transacciones que el receptor suele conocer. Las obtiene de su Mempool, su colección local de transacciones sin confirmar, y solicita las que faltan. Ninguna herramienta comprueba por sí sola todas las reglas de Bitcoin. Un Full Node, o nodo completo, valida bloques y transacciones de manera independiente según las reglas de la red. Una cartera ligera que solo revisa cabeceras e inclusión de su transacción hace una comprobación más limitada. Ahorrar datos y validarlos por completo son propiedades distintas. [1] [5]

BIP 158 especifica el formato. El filtro basic incluye el scriptPubKey, el script que define las condiciones de gasto, de las nuevas salidas salvo las que empiezan por OP_RETURN. También incluye los scripts de salidas anteriores gastadas en el bloque. En los datos de entrada se exceptúa la coinbase, primera transacción del bloque que distribuye la recompensa del minero y no gasta salidas anteriores ordinarias. Sus nuevas salidas siguen las mismas reglas de inclusión que las demás salidas nuevas. Se omiten los elementos vacíos. La cartera debe convertir la dirección al script correcto; buscar su texto impreso no basta. El filtro no es un buscador general de identificadores de transacción txid, datos witness como las firmas, ni notas arbitrarias. [2] [3]

Tras descargar un bloque, Anna puede descubrir que no contiene nada suyo. Esa coincidencia falsa es el coste habitual de un filtro pequeño, no por sí misma prueba de un fallo. Técnicamente, los elementos se convierten en huellas numéricas, se ordenan y sus diferencias se guardan de forma compacta con codificación Golomb-Rice. Para basic se usan P=19 y M=784931. Una consulta sobre un elemento ausente tiene una probabilidad aproximada de coincidencia de 1/M; vigilar más elementos ofrece más oportunidades de coincidencia. No es una tasa fija de error para toda la cartera. Un filtro correctamente construido no omite un elemento incluido. El resultado negativo exige un filtro correcto, un tipo de dato cubierto y una consulta adecuada. [2]

BIP 157 define el transporte y las cabeceras enlazadas de los filtros. Cada cabecera conecta el hash, una huella criptográfica del filtro actual, con la cabecera anterior. Cambiar el filtro rompe el enlace esperado. Sin embargo, esa cadena no forma parte de la cabecera del bloque de Bitcoin y la minería no compromete directamente su contenido. Un nodo deshonesto puede preparar filtros falsos con huellas enlazadas matemáticamente correctas. No cambia Bitcoin, pero puede ocultar información a un cliente aislado. Por eso comprobar los enlaces debe ir acompañado de verificar que los datos son correctos. [1]

BIP 157 se basa en comparar nodos contando con al menos una fuente honesta. Si discrepan, el cliente puede localizar la primera divergencia y verificar el filtro con los datos originales. Para construir basic quizá no baste el nuevo bloque: también hacen falta los scripts de salidas anteriores que gastan sus transacciones. Una reorganización requiere atención especial: la red cambia a otra rama de bloques válidos con mayor trabajo acumulado. La cartera debe enlazar los filtros con la nueva rama y actualizar historial y saldo. La misma altura, es decir, posición en la cadena, no identifica necesariamente el mismo bloque. [1] [3]

La cartera necesita filtros disponibles y una forma de obtener los bloques completos seleccionados. Un nodo puede borrar bloques antiguos después de crear sus filtros; entonces otra fuente debe proporcionarlos. En Bitcoin Core, getblockfilter devuelve el filtro y su cabecera para un bloque concreto si está activado el índice correspondiente. Que el comando funcione no demuestra que exista un servicio público P2P para otros nodos ni acceso a toda la historia. Los filtros de bloques existentes tampoco anuncian transacciones sin confirmar en el Mempool. Para mostrar un pago pendiente hace falta otro mecanismo. Estos detalles operativos determinan si una cartera ligera funciona bien de verdad. [1] [4]