Qué pasó
El 13 de agosto de 2026, Bitcoin Core integró el pull request #35951, que agrega un solo párrafo a las notas de la próxima versión. La nota dice que "Support for the legacy ElGamal (type 0) encryption type when creating I2P sessions is being sunset by the I2P network and will be removed from bitcoind on or before v34", y que los nodos en I2P que corran una versión de Bitcoin Core anterior a v26.1 "will soon only be able to connect to other legacy ElGamal I2P peers and will be increasingly isolated from the rest of the network, with a reduced anonymity set."
Qué cambia
I2P es una de las redes por las que un
nodo de Bitcoin puede ser accesible en lugar de la internet abierta.
Un nodo que la usa publica un lease set: el registro que otros routers leen para averiguar
cómo llegar hasta él. Ese registro va cifrado, y ambos extremos tienen que coincidir en el
esquema. Cuando Bitcoin Core abre una sesión con el router I2P local le pasa una lista de
preferencia, i2cp.leaseSetEncType, que en master hoy dice
4,0: preferir ECIES-X25519,
aceptar ElGamal, un esquema de clave pública temprano que
viene de los años ochenta.
Por qué está ahí la segunda entrada quedó dicho con claridad cuando se agregó, en #29200 en enero de 2024: "A Bitcoin Core node may only connect to a peer destination via I2P if both sides have sessions with the same encryption type." Eso convierte la lista en una superficie de compatibilidad y no en un ajuste de seguridad: cada entrada que se conserva es una población de pares todavía alcanzable, y cada entrada que se quita es una población que deja de serlo.
El cambio siguiente, #35696, propone dejar la
lista en 6,4: ML-KEM-768 primero, ECIES-X25519 después, ElGamal ausente. Un mantenedor de
I2P señala en ese hilo que "Java I2P and i2pd have supported type 6 since API 0.9.67 (Java
I2P 2.10.0, i2pd 2.58.0, 2025-09)". La nota de versión es lo que llegó primero, y a
propósito: la retirada se anuncia bastante antes de que el respaldo desaparezca de verdad.
Qué no cambia
Nada de esto toca la criptografía que protege las monedas. Un lease set es cómo se encuentra a un nodo, no cómo se produce una firma. Agregar un intercambio de claves post-cuántico a un registro de I2P no hace nada por las claves que autorizan un gasto, y conviene decirlo porque "post-cuántico" es la etiqueta bajo la que se va a archivar esta noticia.
El cambio de código tampoco está integrado. Master sigue pidiendo 4,0. Lo que aterrizó el
13 de agosto es la frase que avisa a quien opera un nodo de lo que viene, y eso es todo el
contenido de la noticia.
Y la población afectada es pequeña. I2P es una opción que hay que configurar a mano, y la mayoría no lo hace. Quien nunca la haya configurado no se ve alcanzado por nada de esto.
Contexto
El esquema concreto no es lo interesante. Lo es la forma del problema: retirar una primitiva criptográfica en una red viva solo funciona si el respaldo sobrevive a la transición, y el presupuesto de migración es exactamente el hueco entre la fecha en que el tipo nuevo quedó utilizable (septiembre de 2025, según el mantenedor citado arriba) y la fecha en que el viejo desaparece (v34 o antes). Si se anuncia demasiado tarde, la nota deja gente colgada. Si el respaldo dura demasiado, todo el que lo conservó sigue siendo alcanzable en el ajuste más débil. Agilidad criptográfica es el nombre de tratar ese hueco como algo que se planifica en vez de descubrirlo. La versión de Bitcoin Core es una nota de publicación y un plazo expresado en versiones, no en fechas.