Etiquetas de billetera y BIP-329

Restauras la billetera y las etiquetas han desaparecido

Imagina que durante dos años has anotado de dónde viene cada moneda: «pago de cliente», «compra en exchange con KYC», «cambio». Un día pierdes el móvil, restauras la billetera (wallet) con tu seed phrase y los fondos están todos. Las notas no. Todas las salidas aparecen sin nombre, y ya no sabes cuál de ellas puedes mezclar con cuál.

No es un fallo. Las etiquetas no están en la cadena de bloques ni se derivan de la seed phrase. Son metadatos locales que guarda tu programa. Si tu billetera no las mete en su propia copia de seguridad ni las sincroniza, y no has exportado una copia aparte, se pierden al restaurar.

Para qué sirve una etiqueta

Bitcoin funciona con el modelo UTXO: cada UTXO tiene un origen. Una etiqueta lo recuerda: «viene de un exchange», «es cambio de tal pago», «me lo envió un desconocido». El propio BIP-329 la justifica así: indica el origen de los fondos y ayuda a evitar filtraciones de información privada al gastar.

Esto es la materia prima del coin control. Cuando eliges a mano qué UTXO gastas, las etiquetas te dicen cuáles no deben ir juntos en la misma transacción. Por qué juntarlos los une a ojos de un observador lo explica consolidación de UTXOs. Y la etiqueta de una dirección te recuerda por qué conviene no reutilizarla. Aquí solo importa una cosa: la etiqueta informa, pero quien evita la mezcla es la selección manual. Etiquetar no sustituye al coin control.

El formato: un objeto JSON por línea

BIP-329, «Wallet Labels Export Format», lo escribió Craig Raw, autor de Sparrow, y se le asignó número el 23 de agosto de 2022. A 7 de octubre de 2026 sigue en estado Draft (README de bitcoin/bips). No es un estándar cerrado, y eso conviene tenerlo presente.

El fichero es JSON Lines: un objeto JSON por línea, codificado en UTF-8 y con extensión .jsonl. Cada objeto debe llevar type y ref. El campo label es opcional y el BIP sugiere un máximo de 255 caracteres, sin saltos de línea. Los tipos definidos son siete:

• tx: el ref es el txid.
• addr: una dirección.
• pubkey: una clave pública en hexadecimal.
• input y output: txid:índice.
• xpub: una clave extendida, como las de las billeteras HD.
• spscan: la clave de escaneo de una billetera de pagos silenciosos, en la forma que define su descriptor (BIP-392). Se añadió el 27 de abril de 2026.

Hay dos campos más que merecen atención. origin indica de qué cuenta sale la etiqueta, con la sintaxis abreviada de un descriptor de salida, útil cuando una misma seed tiene varias cuentas. Y spendable, que solo se admite en output, vale false si la billetera no debe gastar esa salida. Es la marca de «congelado», que se añadió en junio de 2023 porque muchas billeteras ya permitían congelar y esa marca se perdía al migrar (PR #1452 de bitcoin/bips).

Desde el 25 de febrero de 2025 hay además campos opcionales de datos: altura y hora del bloque, comisión, valor, tipo de cambio en el momento (rate) o valor razonable de mercado (fmv). El exportador los incluye si los tiene a mano. Sparrow los exporta desde la 2.1.3, de febrero de 2025.

Un ejemplo, con datos inventados

Ejemplo ficticio. Ningún txid, dirección ni clave de abajo existe. Sirve solo para ver la forma del fichero.

{"type":"tx","ref":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","label":"Compra en exchange (ejemplo)","origin":"wpkh([00000000/84'/0'/0'])"}
{"type":"output","ref":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:0","label":"KYC, no mezclar (ejemplo)","spendable":false}
{"type":"addr","ref":"DIRECCION_FICTICIA","label":"Factura cliente 0001 (ejemplo)"}
{"type":"xpub","ref":"XPUB_FICTICIA","label":"Cuenta ahorro (ejemplo)"}

Al importar, la billetera de destino engancha cada etiqueta al objeto que tiene el mismo type y ref. La segunda línea es la útil para el coin control: si la billetera de destino guarda ese campo, la salida queda congelada y no se gastará hasta que la descongeles. Fíjate en que false va sin comillas. Escrito "false", entre comillas, es un texto y no un valor booleano, y el BIP avisa de ese fallo al editar el fichero a mano. Congelar sirve, por ejemplo, para el polvo que te manda un desconocido o para monedas con KYC que no quieres mezclar.

El fichero cuenta tu historial

Aquí está el riesgo. El fichero no permite gastar nada, pero tampoco es inofensivo. Una exportación habitual contiene xpub, direcciones, txids, nombres de cuenta y notas. Con eso, quien lo lea ve el historial completo de esa billetera y, sobre todo, su contexto: qué pagos son de quién y qué parte de tus fondos llegó con KYC. Es más revelador que una xpub sola, porque añade el «quién» y el «para qué». Si quieres entender qué te queda de pseudonimato después de entregarlo, la respuesta es: poco.

El BIP lo dice sin rodeos: hay que tener cuidado al exportar, porque los datos son sensibles. Recomienda cifrar el fichero cuando viaja por redes no confiables, sugiere cifrarlo también guardado y pide borrar cuanto antes la exportación sin cifrar. La ayuda de BitBox (actualizada el 6 de julio de 2026) pide tratar el fichero como confidencial, porque cualquiera que acceda a él puede conocer datos de tu billetera y de tu historial. Ninguna de las billeteras de la lista de abajo documenta que lo cifre por ti. Cífralo tú.

En la práctica: exporta a una carpeta que no se sincronice con la nube y cífralo enseguida, con un contenedor cifrado, una herramienta como age o GPG o un .zip cifrado con AES-256. Ojo con el zip: en 7-Zip hay que elegir AES-256 a mano, porque por defecto usa ZipCrypto, y el zip -e de la terminal también usa ese cifrado antiguo y débil. Después borra la copia en claro y vacía la papelera. En el móvil, la exportación sale por el menú de compartir, y lo fácil es mandarla sin querer a una app de notas o a la nube. Si el fichero llegó a una carpeta sincronizada, bórralo también de los eliminados recientes del servicio. Si tienes copias automáticas del equipo (Time Machine, el historial de archivos de Windows), la versión en claro puede seguir en ellas. Guarda solo la copia cifrada. La contraseña, en otro sitio, por ejemplo en tu gestor de contraseñas, nunca junto al fichero. Y no uses como contraseña tu passphrase ni palabras de tu seed. Si pierdes la contraseña, pierdes las etiquetas, no los fondos.

Quién lo soporta y quién no

El soporte es desigual y cambia. A 7 de octubre de 2026, este es el soporte documentado por cada proyecto:

• Sparrow importa y exporta desde la 1.7.2, de febrero de 2023. Desde la 2.5.3, de julio de 2026, solo escribe spendable: false en los UTXO congelados.
• Liana exporta etiquetas en BIP-329 desde la v10.0, de abril de 2025, y su copia de seguridad, que las incluye, sirve para restaurarlas en Liana.
• BitBoxApp exporta e importa nombres de cuenta y notas de transacción.
• BlueWallet importa y exporta desde la 8.0.2, de octubre de 2026, que ya está en App Store y Google Play. Solo maneja las notas de transacción (registros tx) y al importar ignora los demás.
• BTCPay Server exporta las etiquetas de transacciones desde la 1.9.0, de abril de 2023, e importa desde la 2.4.1, de julio de 2026.
• Nunchuk importa y exporta desde su app, pero no sigue del todo el formato (ver abajo).
• Electrum exporta etiquetas en un formato propio. BIP-329 no está en la versión publicada (la 4.8.2, de septiembre de 2026): su PR #8614 sigue abierta.

Lo de Nunchuk sale de leer su código fuente (libnunchuk, tal como estaba el 19 de agosto de 2026), no de probar la app. Al importar solo lee los registros tx y output. Escribe spendable entre comillas, como texto, justo el fallo del que avisa el BIP. Al importar, no reconoce un true sin comillas y deja esa salida congelada. Y al revés: si un registro output no trae spendable, la descongela, aunque el BIP pide no tocar ese valor cuando falta. Además, un registro tx u output sin label, que el BIP permite, hace fallar la importación en ese punto. Si migras desde o hacia Nunchuk, prueba antes con pocas etiquetas y revisa qué salidas quedan congeladas y cuáles no. Nada de esto toca los fondos: lo peor es tener que congelar o descongelar salidas a mano.

Otras billeteras aparecen en listas comunitarias, pero sin nota de versión ni documentación propia que lo confirme. Además, el BIP no define qué hacer cuando hay conflictos al importar. El importador puede ignorar registros que no guarda o truncar etiquetas largas. Antes de cambiar de billetera, haz la prueba con una cuenta pequeña y compara.

Un uso posible: la contabilidad

Los campos de hora, valor, comisión y tipo de cambio permiten reconstruir cuánto valía cada movimiento y cuándo ocurrió. Eso puede servir como apoyo para llevar tus cuentas. El texto del BIP no habla de impuestos, así que esto es una posible aplicación y no una norma. Qué debes declarar y cómo se calcula es otro asunto, que se trata en fiscalidad en España.

Qué significa esto para ti

Dos hábitos y un recordatorio. Etiqueta el origen de cada entrada en cuanto llega, no seis meses después. Exporta el fichero de etiquetas después de cada cambio importante, guárdalo cifrado y aparte de la seed, y borra la copia sin cifrar. Y recuerda que la seed no restaura las etiquetas, ni tampoco el descriptor de una configuración compleja, como las que usan Miniscript o las billeteras con timelock. Ese descriptor también se respalda aparte.