Glosario / Referencia para desarrolladores
MSG_FILTERED_WITNESS_BLOCK
- ¿Qué es MSG_FILTERED_WITNESS_BLOCK?
- El tipo de bloque filtrado con testigo figura en la lista de tipos reservados de BIP144 y en el enum del código fuente de Bitcoin Core, sin ninguna implementación detrás en ninguno de los dos sitios.
Se especifica en el BIP-144.
MSG_FILTERED_WITNESS_BLOCK es el código de inventario 0x40000003, reservado cuando en 2016 se redactaron las reglas de SegWit para los pares y que nunca recibió una implementación. Bitcoin Core lo incluye como miembro del enum, con un comentario que deja constancia exactamente de eso. La funcionalidad de billetera ligera que habría ampliado, el filtrado de Bloom de BIP37, se desactivó de forma predeterminada en Bitcoin Core 0.19.0, lo que a usted solo le importa si la billetera de su teléfono todavía depende de él.
Cómo funciona
Estado: reservado y nunca implementado. BIP144 dio nombre al tipo; Bitcoin Core lo incluye como miembro del enum en src/protocol.h, con un comentario que deja constancia de que no existe ningún manejador. El filtrado de BIP37 al que habría servido está desactivado de forma predeterminada desde Bitcoin Core 0.19.0, en noviembre de 2019, y los filtros compactos de bloques de BIP157 y BIP158 son su reemplazo.
Entender la brecha exige entender qué era un bloque filtrado. Un cliente ligero que usa BIP37 envía un mensaje filterload que describe, de forma aproximada, las direcciones que le interesan. Después solicita el tipo de inventario 3, MSG_FILTERED_BLOCK, y el nodo que lo sirve responde con un mensaje merkleblock: el encabezado de bloque de 80 bytes, un recuento de transacciones, una rama de Merkle parcial y un campo de bits que indica por dónde recorrer el árbol. Las transacciones que coinciden llegan después como mensajes aparte. El cliente comprueba que cada una cuelga realmente de la raíz de Merkle del encabezado del bloque, y lo hace usando solo los txid.
Los testigos nunca entraron en esa aritmética. Como la raíz de Merkle se construye a partir de los txid, un cliente ligero puede demostrar la inclusión sin una sola firma, así que las transacciones que venían después se enviaban sin datos de testigo. El tipo reservado, el 3 con el indicador de testigo añadido, 0x40000003, habría permitido a un cliente solicitar esas transacciones completas. Nadie lo implementó, porque nadie que produjera billeteras ligeras quería más BIP37.
La razón es la privacidad, no el esfuerzo. El filtro que sube un cliente le indica al nodo que lo sirve, de forma aproximada, qué direcciones le pertenecen, y las investigaciones realizadas hasta mediados de la década de 2010 mostraron que esos filtros revelaban mucho más de lo previsto. La respuesta de Bitcoin Core fue dejar de servirlos de forma predeterminada en lugar de reparar el diseño. BIP158, en cambio, invierte el flujo: el nodo construye un pequeño filtro con codificación Golomb por bloque, calibrado para una proporción de falsos positivos de uno entre 784.931, y lo publica. El cliente descarga los filtros, los prueba localmente y solo descarga un bloque entero cuando hay una coincidencia, así que el servidor no averigua nada sobre qué direcciones le interesaban.
Dónde aparece
Casi en ninguna parte, que es la respuesta honesta para cualquiera que encuentre MSG_FILTERED_WITNESS_BLOCK en una tabla de referencia.
Busque la constante con grep en Bitcoin Core y encontrará un único miembro del enum. Implementaciones alternativas como btcd replican el nombre en sus paquetes wire por completitud, de nuevo sin ningún comportamiento detrás. Ninguna billetera lo ha enviado nunca.
Donde el tema sí afecta a un comprador es en cómo obtiene sus datos una billetera móvil. Si una billetera se describe como SPV y se conecta a nodos públicos al azar con filtros de Bloom, está usando un mecanismo que la implementación de referencia dejó de servir de forma predeterminada hace años, y les está contando a esos nodos algo sobre sus direcciones. Las billeteras basadas en filtros compactos de bloques, el diseño que hay detrás de Neutrino, de lnd, exigen mucho menos. Una billetera conectada al servidor de su propio proveedor es la tercera opción, y la más común: rápida, privada frente a desconocidos y totalmente visible para el proveedor.
MSG_FILTERED_WITNESS_BLOCK frente a bloque de Merkle
Un bloque de Merkle es la respuesta; MSG_FILTERED_WITNESS_BLOCK es una solicitud que nunca se implementó para producir uno. El mensaje merkleblock es una estructura real e implementada que demuestra que un conjunto de transacciones pertenece a un bloque sin enviar el bloque. La variante reservada con testigo solo habría cambiado lo que venía después de esa prueba, es decir, si las transacciones coincidentes llegaban con sus firmas. Como las pruebas de inclusión funcionan con los txid, la funcionalidad que falta no le costó nada a nadie.