BIP324 describe cómo cifrar los mensajes que intercambian los nodos de Bitcoin. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. Estas conexiones directas entre participantes de la red se denominan P2P; su variante cifrada se conoce como v2 transport. Quien solo escucha una conexión no debería poder leer fácilmente su contenido. Sin embargo, el cifrado por sí solo no confirma con qué nodo estás hablando realmente. La cadena pública y las reglas de validez de las transacciones no cambian.
Un bloque es un lote de transacciones incorporado al historial compartido de Bitcoin. Los bloques son públicos, pero observar cómo se propagan no equivale a leer la cadena ya formada. Quien vigila una conexión sin cifrar también ve el orden de los mensajes, las consultas y cuándo un nodo retransmitió una transacción. Eso puede ayudar a vincular actividad de red con personas. BIP324 limita esa lectura fácil del contenido por un observador pasivo. [1] [2] [7]
Dos nodos compatibles acuerdan claves al conectarse y después se comunican de forma cifrada. No necesitan conocer previamente la identidad del otro ni tener un certificado de una autoridad central. Por eso, cifrado no significa fiable. El nodo receptor, naturalmente, lee los mensajes y aún puede pertenecer a un atacante. [1]
Al iniciar una conexión, en un proceso llamado handshake, ambos nodos generan claves temporales. Una clave privada es un valor numérico secreto; la clave pública correspondiente puede compartirse con otras personas. Mediante ECDH, cada uno calcula el mismo secreto compartido sin intercambiar claves privadas. De ese secreto se derivan las claves que protegen el tráfico. ElligatorSwift codifica las claves públicas de modo que esa parte del intercambio parezca aleatoria y sea más difícil reconocerla por un patrón fijo. Son exclusivamente claves de la conexión de red. No son claves privadas para gastar bitcoin ni una seed, el valor secreto inicial del que se derivan las claves de la cartera. Activar el transporte cifrado no exige compartir la copia de seguridad de una cartera. [1] [8]
Imagina que alguien intercepta un mensaje y modifica su contenido por el camino. BIP324 utiliza ChaCha20Poly1305: cifrado acompañado de una comprobación de que el mensaje corresponde a la clave de la conexión y no ha sido alterado. Sin esa clave, un atacante no puede limitarse a cambiar los datos y producir un mensaje válido. Pero la comprobación no demuestra que compartas la clave con el nodo previsto. Un intermediario activo puede hacerse pasar por el otro extremo ante cada parte durante el establecimiento de las conexiones. Así mantiene dos conexiones cifradas independientes y lee y retransmite los mensajes entre ellas. Proteger los mensajes y verificar el otro extremo son tareas diferentes. [1]
Las claves cambian durante la comunicación. Si los secretos anteriores se borran correctamente, obtener después las claves actuales no permite descifrar automáticamente toda la grabación previa. Esta propiedad se llama forward secrecy. No protege los mensajes que el otro nodo ya ha leído o guardado. Tampoco ayuda frente a un atacante que mantiene el control del equipo; además, el grupo de mensajes más reciente puede seguir expuesto. [1]
El transporte v1 sigue disponible por compatibilidad. Si falla una conexión v2, el programa puede intentar v1. Un atacante activo puede bloquear las conexiones cifradas e intentar forzar esa vuelta sin cifrado. BIP324 encarece la vigilancia pasiva, pero no promete resistencia general al downgrade ni disponibilidad de la conexión. [1] [4]
BIP324 no oculta la dirección IP ni todos los patrones de tiempo y volumen del tráfico. La dirección IP es la dirección de red que utiliza un dispositivo para comunicarse por internet. Tor puede abordar otra parte del problema, pero combinarlos tampoco garantiza anonimato. Llegue como llegue un mensaje, el Full Node debe verificar transacciones, firmas y bloques. El cifrado por sí solo no resuelve un Eclipse Attack, en el que atacantes rodean al nodo. [1] [6]
Bitcoin Core 26.0 incorporó v2 en 2023, inicialmente desactivado por defecto. La versión 27.0 lo activó por defecto. El año de esta entrada señala por tanto la primera compatibilidad en Bitcoin Core, no el origen de la propuesta. El transporte se negocia por conexión: que el programa lo admita no significa que todos sus peers usen v2. [3] [4]
Quien administra Bitcoin Core puede consultar el estado con bitcoin-cli getpeerinfo. La consulta usa RPC, una interfaz para controlar el nodo y obtener información; este comando no difunde transacciones en la red Bitcoin ni cambia ajustes. La salida muestra cada conexión por separado. En transport_protocol_type, v2 significa transporte cifrado, v1 el transporte antiguo sin cifrar y detecting que la elección sigue sin resolverse. session_id contiene el identificador de una conexión v2; de lo contrario está vacío. Su presencia no verifica por sí sola el otro extremo. Dos operadores pueden comparar el identificador de su conexión mutua mediante otro canal de confianza para detectar un intermediario; las conexiones habituales no realizan esa comprobación automáticamente. El resultado describe ese enlace, no todo el recorrido de una transacción por la red. La salida también contiene datos de red que no es necesario publicar. [5] [1]
BIP324 enumera como autores a Dhruv Mehta, Tim Ruffing, Jonas Schnelli y Pieter Wuille. El número se asignó en 2019; al revisarlo el 17 de octubre de 2026 su estado es Deployed. Adoptarlo no requiere un Soft Fork ni cambiar la oferta de bitcoin. Es una mejora gradual de la comunicación, cuyo beneficio depende de la implementación y de las conexiones realmente utilizadas. [1]
Para obtener la imagen más completa, lee esta entrada junto con Full Node, Eclipse Attack, Privacidad en Bitcoin, Bitcoin Core. También enlazan con esta entrada Mix Network.