Qué pasó
El 21 de agosto de 2026 Electrum integró dos cambios pequeños en el código que lee una clave extendida: uno rechaza una clave extendida privada cuyo campo de clave no empieza por un byte cero (commit ea285d5e), y el otro rechaza una clave maestra que lleva huella dactilar del padre o número de hijo (commit afb5c7ad). Ambos casos salen directamente de BIP-32, cuyo quinto conjunto de vectores de prueba existe precisamente para esto: "Estos vectores comprueban que las claves extendidas inválidas se reconocen como inválidas".
Qué cambia
Una clave extendida son 78 bytes envueltos en base58check, y la disposición es fija: cuatro bytes de versión, uno de profundidad, cuatro de huella dactilar del padre, cuatro de número de hijo, treinta y dos de chain code y treinta y tres de clave. En una clave privada esos últimos treinta y tres son un byte cero seguido del secreto de 32 bytes. En una pública son un punto comprimido, que empieza por 0x02 o 0x03. Dos de los campos los decide la construcción y no una elección: una clave maestra no tiene padre, así que su profundidad es cero y tanto su huella dactilar del padre como su número de hijo deben ser cero también.
Electrum leía los campos y no los comprobaba. En una clave privada tomaba los últimos treinta
y dos bytes del registro y los usaba como secreto, dijera lo que dijera el byte anterior. La
consecuencia se ve en el vector que BIP-32 etiqueta como "prvkey version / pubkey mismatch": su
campo de clave es una clave pública comprimida, 0x03 seguido de una coordenada x, bajo una
cabecera xprv. Al decodificarlo, el parser antiguo se saltaba el 0x03, tomaba los 32 bytes
siguientes y construía un monedero cuya clave privada es un número publicado en la propia
cadena. Los otros dos vectores de ese grupo ponen 0x04 y 0x01 en la misma posición, y se
leían igual.
La comprobación de la clave maestra es más callada y merece entenderse. La
seed que está en la raíz de un monedero deriva una clave
extendida sin padre, así que los huecos de huella dactilar y número de hijo no tienen nada que
describir. Los vectores de BIP-32 los rellenan con 0x01010101 y esperan que la clave se
rechace. Un parser que los acepta permite que una misma clave tenga muchas cadenas distintas
que decodifican a ella: el mismo chain code, el mismo material de clave, texto diferente.
Montar un multisig consiste en copiar claves extendidas entre
monederos como texto, y allí donde se compare ese texto, dos formas de escribir una clave son
dos claves.
Ninguna de las dos comprobaciones es información nueva. Las dos se escribieron en la lista de pruebas del propio estándar para que las implementaciones pudieran averiguar si coincidían, que es el sentido de publicar vectores inválidos junto a los válidos.
Qué no cambia
Nadie tenía monedas en riesgo mientras esto faltaba. Una clave extendida malformada no aparece usando un monedero con normalidad; aparece porque algo te la ha entregado, y el comportamiento antiguo convierte una cadena mala en un monedero que parece funcionar en lugar de en un mensaje de error. Ese es el fallo que se cierra: basura dentro, monedero verosímil fuera.
Tampoco deja el parser completo. Las dos comprobaciones cubren siete de las dieciséis entradas de la lista de claves inválidas de BIP-32: las tres claves privadas con un byte de prefijo equivocado y las cuatro claves maestras que llevan metadatos de padre. Las otras nueve se topan con la comprobación de longitud, el checksum de base58, la cabecera de versión o el constructor de la clave. Y nada de eso dice nada sobre una clave bien formada que sencillamente no es tuya.
El test nuevo del caso de la clave privada es además más flojo de lo que parece. Enumera tres vectores, pero a los dos primeros literales de cadena les falta la coma entre ellos, así que Python los une en una sola cadena de 222 caracteres que falla en su checksum mucho antes de llegar a la comprobación nueva. Se ejercitan dos de los tres casos. La comprobación en sí cubre los tres.
Y nada de lo instalado lo lleva. La versión más reciente de Electrum, la 4.8.1, es del 10 de agosto de 2026, anterior a ambos commits; estos están en la rama de desarrollo.
Contexto
Las claves extendidas son el formato que mueve el resto de la fontanería de un monedero: descriptores, configuración de cofirmantes, un hardware wallet diciéndole a un portátil qué puede observar. Por eso la pregunta de qué acepta un monedero vuelve una y otra vez en trozos pequeños. Core añadió un RPC para entregar un xpub en una ruta elegida este mes, y llegó una corrección para una fusión que podía escribir dos veces el mismo registro de xpub en una transacción parcialmente firmada.
El patrón en los tres es el mismo. La criptografía no es donde está el problema. El problema está en la contabilidad que la rodea: qué significan qué bytes, qué campos pueden variar y si dos cosas que parecen iguales lo son. La lista de claves inválidas se añadió a BIP-32 en un commit titulado added invalid extended keys vectors, escrito en mayo de 2020 e integrado aquel noviembre, y las cadenas que contiene no han cambiado desde entonces. Seis años después siguen encontrando parsers.