Filtro de Bloom

El diseño cambiaba ancho de banda por lo que sus autores esperaban que fuera privacidad, y la privacidad nunca llegó. Bitcoin Core dejó de servir estos filtros de forma predeterminada en la versión 0.19.0, publicada en noviembre de 2019, después de que años de investigación mostraran cuánto delatan. Una billetera que todavía depende de uno le está entregando a la máquina de un desconocido una lista aprovechable de las monedas que usted posee.

Cómo funciona

Estado: el filtrado de Bloom de BIP37 se desactivó de forma predeterminada en Bitcoin Core 0.19.0, en noviembre de 2019, y los filtros compactos de bloques de BIP157 y BIP158 asumieron la tarea de las billeteras ligeras.

Un filtro de Bloom es un vector de bits más un puñado de funciones hash. Para insertar un elemento se calcula su hash de varias maneras, se toma cada resultado módulo la longitud del vector y esos bits se establecen en uno. Para comprobar un elemento se calcula su hash de las mismas maneras y se miran esos bits. Si alguno de ellos es cero, es seguro que el elemento nunca se insertó; si todos son uno, el elemento probablemente se insertó, o bien otras inserciones establecieron por casualidad los mismos bits. Los falsos negativos no pueden darse. Los falsos positivos sí, y su proporción es el parámetro que se calibra.

BIP37 definió la aritmética. Un filtro tiene un tope de 36.000 bytes y de 50 funciones hash, y el hash se calcula con la versión 3 de la función Murmur de 32 bits, inicializada con el número de hash multiplicado por 0xFBA4C795 más un ajuste (tweak) elegido por el cliente. Tres mensajes lo gobiernan: filterload instala un filtro en la conexión, filteradd lo amplía y filterclear lo elimina. Una vez establecido el filtro, el par responde a una solicitud de bloque con un mensaje merkleblock que lleva el encabezado de 80 bytes, las transacciones que coincidieron y las ramas de Merkle que demuestran que pertenecen a ese bloque. Más tarde, BIP111 añadió el bit de servicio NODE_BLOOM para que un nodo pudiera anunciar si iba a colaborar o no.

Todo el argumento de la privacidad descansaba en esa proporción de falsos positivos. Si se amplía el filtro y se captan transacciones ajenas junto con las propias, se supone que un observador no puede distinguir unas de otras. No se sostiene. Un trabajo académico publicado en 2014 demostró que un filtro con un número realista de direcciones delata la mayoría de ellas, y que dos filtros cargados por la misma billetera pueden intersecarse para quitar el camuflaje. Volver a conectarse a un par nuevo con un filtro nuevo empeora el problema en lugar de mejorarlo.

El otro fallo era más sencillo de explicar. Servir un filtro significa escanear bloques del disco a instancias de un desconocido, así que cualquier par podía hacer que un nodo con un disco mecánico realizara una enorme cantidad de trabajo no remunerado. Ese argumento de denegación de servicio, y no la investigación sobre privacidad, es lo primero que mencionan las notas de la versión 0.19.0.

Dónde aparece

Los filtros de Bloom sobreviven sobre todo en software escrito antes de 2019 y en archivos de configuración que sortean su ausencia.

Las billeteras de Android construidas sobre la biblioteca bitcoinj usaban BIP37 como su único backend de cadena, y algunas siguen instaladas. Bisq también lo necesitaba, y por eso su documentación solía indicar a la gente que añadiera peerbloomfilters=1 a la configuración de su propio nodo. Esa línea es lo que lo delata: cuando un programa le solicita reactivar el filtrado de Bloom en un nodo que usted ejecuta, está solicitando una técnica que el cliente de referencia desactivó por buenas razones.

El reemplazo moderno funciona en sentido inverso. Con BIP157 y BIP158, el nodo construye un filtro por bloque y lo publica para todos, y la billetera busca las coincidencias en su propio hardware, así que nada sobre sus direcciones sale del dispositivo.

Filtro de Bloom frente a SPV

Un filtro de Bloom era un mecanismo de entrega; la verificación de pago simplificada es un modelo de confianza, y confundir ambos lleva a suponer que el modelo murió con el mecanismo. SPV significa comprobar que una transacción está bajo la raíz de Merkle de un encabezado de la cadena con más trabajo acumulado, sin validar el resto del contenido de esa cadena. Ese razonamiento no ha cambiado. Lo que cambió es cómo encuentra una billetera ligera las transacciones que vale la pena comprobar: antes difundía una representación con pérdidas de sus propias direcciones y esperaba lo mejor, y ahora descarga un filtro por bloque y lo prueba en casa.