Transporte cifrado BIP-324

Cuando dos nodos admiten BIP-324, realizan un intercambio de claves efímeras antes de que se envíe ningún mensaje de Bitcoin y luego envuelven cada mensaje en ChaCha20Poly1305. La especificación se marcó como final el 10 de julio de 2024, y un nodo anuncia su compatibilidad con el indicador de servicio NODE_P2P_V2, el bit 11. Nada cambia en sus monedas: lo que cambia es que un observador pasivo ya no puede leer las transacciones que su nodo retransmite.

Cómo funciona

BIP-324 reemplaza los bytes mágicos de red fijos con los que antes se abría una conexión de bitcoin por un flujo que no tiene ninguna forma reconocible.

El lado que inicia la conexión genera una clave secp256k1 desechable y envía la codificación ElligatorSwift de 64 bytes de su clave pública. Esa codificación es el truco: una clave pública corriente se puede identificar como un punto de la curva, mientras que cualquier cadena de 512 bits es una codificación ElligatorSwift válida, así que los bytes iniciales son, estadísticamente, solo ruido. Después, cualquiera de los dos lados puede añadir hasta 4095 bytes de relleno arbitrario, llamado basura (garbage), para que una conexión no tenga que empezar con exactamente 64 bytes. Ambos extremos ejecutan X-only ECDH (solo coordenada x) y pasan el resultado por HKDF-SHA256 para derivar cuatro claves de cifrado, dos terminadores de basura de 16 bytes y un ID de sesión.

Esos bytes iniciales son la única parte del intercambio que se envía en claro. Después de los terminadores, todo lo que va por la red son paquetes. Un paquete es un campo de longitud cifrado de 3 bytes seguido de un texto cifrado ChaCha20Poly1305 que cubre un encabezado de 1 byte y el contenido, con un costo de 20 bytes más la carga útil. El bit superior de ese encabezado es el bit de ignorar, y un paquete que lo lleva es un señuelo: el destinatario comprueba que se descifra y luego lo descarta, y así es como un nodo puede rellenar su tráfico para disimular el momento en que salió un mensaje real. Las claves avanzan como un trinquete cada 224 paquetes, un intervalo elegido para que un enlace casi inactivo que no envía más que un mensaje ping cada 20 minutos renueve sus claves aproximadamente cada 3,11 días, y ese trinquete es lo que da secreto hacia adelante (forward secrecy) a una sesión.

El diseño se detiene deliberadamente antes de demostrar quién está al otro lado. No hay certificados ni identidades, así que un intermediario decidido todavía puede situarse entre dos nodos. Lo que no puede hacer es situarse ahí de forma barata o invisible: el ID de sesión resulta del intercambio de claves, y si dos operadores se leen mutuamente el suyo en voz alta, verán valores distintos siempre que haya alguien en medio.

Dónde aparece

BIP-324 no deja nada en la blockchain, así que el único lugar donde aparece es entre dos nodos en funcionamiento.

La compatibilidad se anuncia en el gossip de direcciones mediante el indicador NODE_P2P_V2, que los pares conocen por los mensajes addr y addrv2. Esos indicadores pasan por retransmisores en los que no se confía y se combinan con un OR lógico, así que es posible un anuncio falso, y el BIP anima a que un cliente v2 al que desconectan de inmediato vuelva a intentarlo con el mismo par por v1. En sentido contrario, un nodo v2 sigue aceptando a propósito conexiones v1 entrantes, para evitar que la red se divida en dos mitades que no puedan comunicarse entre sí.

El segundo efecto visible son mensajes más cortos. La versión 1 gastaba 12 bytes ASCII en cada nombre de comando; la versión 2 asigna ID de un byte a los 28 tipos de mensaje definidos hasta ahora, de modo que el mensaje inv es un solo byte, el 14, y el mensaje getblocktxn es el 10, y cualquier mensaje que use un ID corto cuesta 3 bytes menos que su forma v1. Lo que no tiene un ID asignado recurre a una codificación de 13 bytes, un byte cero seguido del antiguo nombre ASCII, así que no se pierde nada.

La especificación tiene el estado Deployed (desplegado), incluye vectores de prueba y una implementación de referencia ingenua en Python pensada solo como demostración, y todavía se está editando: la revisión 1.0.2, del 30 de enero de 2026, añadió una tabla de ID de tipos de mensaje en un archivo auxiliar para que otros BIP puedan reclamar ID sin editar el documento principal. El encabezado también deja constancia de que BIP-324 reemplaza a BIP-151.