Qué pasó
El 19 de agosto de 2026 Bitcoin Core fusionó el
pull request 35665, que impide que
combinepsbt produzca un archivo que nada, ni siquiera el nodo que lo produjo, pueda leer
de vuelta. El pull request incluye una reproducción sobre master: combinar dos
transacciones parcialmente firmadas que difieren en un solo campo devuelve un resultado que
decodepsbt rechaza con error code: -22 y el mensaje TX decode failed Duplicate Key, global key "01043587cf00...9c85c2" already provided. También indica la antigüedad del
error: "Esto afecta a todas las versiones desde que se agregó el bucle de fusión en #17034
(v23.0)".
Qué cambia
Un PSBT es el archivo que dos wallets se pasan de una a otra para armar un gasto que necesita más de una firma. Es una lista de registros clave-valor, y su regla central es una regla sobre las claves: "Las claves dentro de cada ámbito nunca deberían duplicarse; todas las claves del formato son únicas. Los PSBT que contienen claves duplicadas son inválidos".
Un tipo de registro lleva una extended public key, para que quien firma pueda deducir qué claves de la transacción pertenecen a qué wallet. En ese registro la clave es la propia xpub, y el valor es su origen: el fingerprint de la clave maestra y el derivation path. Core guardaba la misma información en memoria al revés, según describe el pull request: "Las global xpubs se guardan en un mapa de origen de clave a conjunto de xpubs, mientras que la serialización escribe un registro por xpub, con la xpub como clave".
La fusión seguía entonces la forma de la estructura en memoria y no la del archivo.
Merge une el mapa origen por origen, así que dos PSBT que nombran la misma xpub bajo dos
orígenes distintos producen un resultado que escribe dos veces la misma clave
PSBT_GLOBAL_XPUB. La regla de unicidad vive en la clave; la estructura que se fusionaba no
estaba indexada por ella. En la reproducción, los dos archivos comparten la transacción sin
firmar y la xpub, y "difieren solo en el master fingerprint del registro de global xpub
(00000000 frente a 11111111)", lo cual alcanza.
El arreglo deduplica por xpub al fusionar y conserva el origen que ya estaba presente, algo
que el estándar permite: BIP 174 deja que el Combiner "elija arbitrariamente cuando hay
conflictos", y Core ya resolvía de la misma forma los registros desconocidos y propietarios
en conflicto. La lógica ahora vive en un único helper, MergeGlobalXPubs, compartido por
combinepsbt y joinpsbts.
Qué no cambia
Nadie perdió monedas por esto y nadie podría. El fallo es ruidoso y ocurre al analizar el archivo, no al firmar: el archivo fusionado se rechaza antes de verificar ninguna firma, así que lo que el error destruye es una ronda de coordinación, no dinero. Conviene decirlo con todas las letras porque el error contrario, una fusión que produjera en silencio un archivo de apariencia válida con orígenes de clave equivocados, sí importaría.
El conflicto tampoco se resuelve: se descarta. Conservar el primer origen significa que la afirmación del otro firmante sobre el fingerprint y el derivation path desaparece sin aviso. Si dos dispositivos de un multisig no coinciden sobre de dónde vino una xpub, el archivo fusionado ahora se va a poder leer, y el desacuerdo que registraba no va a estar en él. Verificar que una xpub es realmente propia se sigue haciendo en el dispositivo que firma, que es donde siempre se hizo.
Esto no arregla nada de lo que está instalado. El cambio está en master y, según el propio
pull request, toda versión desde la v23.0 produce el archivo defectuoso, así que hasta que
una versión incorpore el arreglo la respuesta práctica es no combinar PSBT cuyos orígenes de
global xpub estén en conflicto. La mitad de joinpsbts es preventiva más que correctiva: el
autor apunta que su bucle de xpubs "por ahora no tiene efecto observable, ya que las xpubs
recolectadas nunca llegan al PSBT devuelto", y que un cambio pendiente aparte volvería
alcanzable ahí el mismo duplicado si el helper compartido no estuviera ya en su lugar.
Contexto
Lo interesante no es el error, sino dónde vivía. Nada fallaba en el formato, ni en la especificación, ni en la criptografía, ni en las firmas. Dos representaciones de un mismo hecho discrepaban sobre cuál era el campo que identifica, y el archivo inválido salió del hueco entre ambas.
Las extended public keys aparecen una y otra vez en esa costura porque un multisig tiene que moverlas para funcionar. Core agregó este mes una forma de entregar una xpub en un path elegido, y BIP-89 llegó a Deployed con el argumento de no entregar ninguna. Qué sabe un co-firmante sobre las demás claves, cómo lo aprende y qué hace cuando dos fuentes discrepan es la misma pregunta en cada uno de esos casos.