Direcciones Bitcoin

Una dirección no es una cuenta

Cuando alguien te dice «mi dirección es bc1q…», ¿qué te está dando exactamente? No es un número de cuenta ni guarda saldo. Es una forma cómoda de escribir un script de salida (scriptPubKey), la condición que bloquea los bitcoin que te envían.

Un ejemplo con un vector de prueba oficial de BIP-173: la dirección bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 se descodifica en el script 0014751e76e8199196d454941c45d1b3a323f1433bd6. Ese script es lo que queda escrito en la salida de la transacción. Es un vector público y su clave privada es conocida (es la 1): no envíes fondos a esa dirección.

Por eso una dirección no «tiene» bitcoin. Los bitcoin están en UTXO bloqueadas por un script. El saldo que enseña un explorador es la suma de las UTXO sin gastar cuyo script coincide con esa dirección. De ahí que el protocolo no tenga forma de «cerrar», «vaciar» o «caducar» una dirección. Lo único que ocurre es que una billetera (wallet) o un servicio dejen de vigilarla.

Qué hay dentro: hash, script o clave

Es frecuente leer que la dirección sale de la clave pública y que no la revela. Es cierto solo en parte. Depende del tipo:

En las direcciones que empiezan por 1 (P2PKH) y en las bc1q de clave simple (P2WPKH), la dirección contiene el hash de la clave pública. La clave se ve cuando se gasta, no antes.

En las que empiezan por 3 (P2SH) y en las bc1q largas (P2WSH), la dirección no contiene el hash de una clave, sino el de un script. Ese script puede llevar una clave o varias, como en una multifirma. BIP-13 lo describe como el hash del script que se usará para gastar las monedas.

En las bc1p (P2TR), la dirección no esconde la clave. El programa de witness son los 32 bytes de la clave de salida de Taproot, y esa clave está a la vista. El vector de BIP-350 bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0 contiene la coordenada x del punto generador de secp256k1, es decir, la clave pública de la clave privada 1. Esa clave privada es conocida por todo el mundo y cualquier fondo enviado ahí se pierde: no la uses.

La tabla de formatos, prefijos y tamaños está en tipos de direcciones. Aquí basta con la idea: la dirección es un script codificado, y lo que revela de tu clave depende del script.

Una dirección nueva por cada cobro

La billetera HD no inventa direcciones al azar. Baja por la cadena de recepción de su seed phrase y entrega la siguiente sin usar. El detalle de las rutas está en rutas de derivación. Una cosa a tener en cuenta: BIP-44 fija un límite de huecos de 20. Si una billetera restaurada encuentra 20 direcciones seguidas sin uso, deja de buscar más allá.

La razón de estrenar una por cobro viene de lejos. La sección 10 del whitepaper (2008) pide usar un par de claves nuevo en cada transacción para que no se puedan vincular a un mismo dueño. BIP-321 (estado Complete) lo repite: lo recomendable es una dirección única por cada transacción en cadena, y una URI con dirección es una instrucción de pago de una sola vez, no un dato personal.

El motivo práctico: la blockchain es pública. Si cobras dos veces en la misma dirección, cualquiera ve que los dos pagos van al mismo sitio. Reutilizar une los cobros, y quien conozca un pago conoce los demás. El daño completo se explica en reutilización de direcciones. Generar direcciones no cuesta nada, así que no hay motivo para ahorrarlas. Lo único que hay que vigilar: si repartes 20 seguidas que nadie paga, un pago que llegue después a la siguiente puede no aparecer al restaurar la billetera (ver el límite de huecos arriba).

No es un límite del protocolo: una dirección admite cualquier número de pagos y no caduca. Es una decisión de privacidad. Bitcoin Core lleva un mecanismo para ayudar: el flag de billetera avoid_reuse, desde la versión 0.19.0.1 (noviembre de 2019), desactivado por defecto. Distingue las direcciones ya usadas y deja sus monedas fuera de la selección, salvo que se lo pidas expresamente. Junto con -avoidpartialspends (v0.17.0), las notas dicen que puede eliminar un problema serio: que alguien rastree tus gastos mandando pagos pequeños a una dirección que ya usaste. Ese tipo de polvo se gestiona con coin control.

Qué comprueba la suma de verificación

Teclear una dirección a mano es una invitación al error. Por eso todas llevan una suma de verificación (checksum), un trozo final calculado a partir del resto. Si cambias algo, el cálculo casi siempre deja de cuadrar y la billetera se niega a pagar.

En las direcciones 1 y 3 (Base58Check), el checksum son los 4 primeros bytes del doble SHA-256 de la versión y el hash (BIP-13 y base58.cpp de Bitcoin Core). Un error al azar se cuela con una probabilidad de más o menos 1 entre 4.300 millones (2^32, cálculo a partir de BIP-13), pero sin garantía para ningún patrón concreto. El alfabeto Base58 deja fuera 0, O, I y l porque se parecen en algunas tipografías (código de Bitcoin Core, base58.h).

En las bc1 (bech32) los últimos seis caracteres son el checksum. BIP-173 lo diseñó para detectar siempre cualquier cambio de hasta 4 caracteres, es decir, letras sustituidas por otras. Con más de 4 sustituciones, la probabilidad de que pasen inadvertidos es inferior a 1 entre mil millones. Con una sola letra cambiada, la billetera lo detecta siempre. El mismo BIP enseña el caso: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 es válida, y bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5, que solo cambia el último carácter, falla el checksum. Ambas son vectores públicos: no envíes fondos a ninguna.

Bech32 tenía un fallo menor. Según BIP-350, si el último carácter es una p, insertar o borrar cualquier cantidad de q justo antes no invalida el checksum. No afectaba a la versión 0 de witness porque sus longitudes son fijas. Bech32m (BIP-350, de diciembre de 2020) lo corrige y mantiene la detección de cualquier sustitución de hasta 4 caracteres. La regla: la versión 0 sigue en bech32 y las versiones 1 a 16, como Taproot, usan bech32m.

Dos detalles más de BIP-173. Una billetera no debe autocorregir: a lo sumo, sugerir en qué parte de la cadena está el error, porque corregir puede convertir una dirección inválida en otra válida pero equivocada. Y en las bc1 no se mezclan mayúsculas y minúsculas: el decodificador rechaza esa mezcla. En los QR se recomienda todo en mayúsculas, porque el modo alfanumérico es un 45 % más compacto.

El prefijo bc o tb, y en las antiguas el byte de versión, separan la red principal de las de pruebas. No te protegen de otras monedas que copian el formato: una dirección antigua de Bitcoin Cash es indistinguible de una de Bitcoin. Antes de pagar, confirma que la dirección es de Bitcoin, no solo que es válida.

Qué no detecta: erratas sí, engaños no

La suma de verificación caza erratas, no engaños. Una dirección ajena pero válida pasa todas las comprobaciones, porque para la billetera es una dirección perfectamente legal. Que empiece por bc1 tampoco demuestra nada: la del atacante también empieza así.

Ahí entra el malware de portapapeles (clipboard hijacker). Electrum lo describe como un programa que vigila el portapapeles y, al ver una dirección Bitcoin, la cambia por otra del atacante. Su consejo: revisar y confirmar los detalles de cualquier transacción antes de firmarla. En 2021 un estudio académico (EthClipper, probado en Ethereum con Trezor, Ledger y KeepKey) combinó ese malware con direcciones fabricadas para parecerse a la original, justo para engañar a quien solo compara unos pocos caracteres en la pantalla del aparato. Hay más en errores de autocustodia.

Una variante es el address poisoning (envenenamiento de direcciones). El atacante manda una cantidad mínima desde una dirección parecida a otra con la que operas, de modo que aparezca en tu historial. Espera que la copies de ahí por error. Las fuentes que lo documentan (Ledger en abril de 2023, Trezor) hablan sobre todo de Ethereum y de redes de comisiones bajas. No hay casos documentados en Bitcoin en esas fuentes, pero el mecanismo funciona igual: cualquiera puede mandar un pago pequeño a cualquier dirección. La defensa es la misma: no copiar nunca de tu historial.

Aquí aparece la comprobación que sí protege. Si recibes una dirección por correo, por mensaje o desde una web, ese canal puede estar manipulado. Para pagar: confirma la dirección por otro canal (una llamada, o un contacto que ya conocías) y compárala entera con la pantalla de la hardware wallet (billetera física) antes de firmar. La pantalla enseña lo que le pasó el ordenador: si el portapapeles ya estaba cambiado, mostrará fielmente la del atacante, así que solo sirve si la comparas con la original. Para cobrar, en cambio, la pantalla es decisiva: muestra la dirección que genera el propio aparato. Cómo comparar tramos y por qué mirar solo el principio y el final no basta se explica en hardware wallets. Las estafas más comunes están en amenazas y estafas.

Cuando una billetera rechaza una bc1p

Si una billetera o un servicio dice que una dirección bc1p no es válida, no tiene por qué estar mal escrita. BIP-350 rompió a propósito la compatibilidad al enviar a las versiones 1 y superiores. Así, un programa antiguo rechaza la dirección en vez de arriesgarse al fallo de la q, y algunos que habrían quemado los fondos al enviar a Taproot ya no pueden hacerlo. Se perdía poco: casi ninguna billetera admitía entonces esos envíos. Un programa que solo conoce bech32 ve un checksum que no cuadra. Su propio vector inválido lo muestra: la misma bc1p0xlxvl… con checksum bech32 en lugar de bech32m.

No se pierden fondos: el pago simplemente no sale. La solución es actualizar la billetera o pedir una dirección bc1q. Bitcoin Core puede pagar a Taproot desde la versión 0.21.1, del 1 de mayo de 2021 (notas de versión y doc/bips.md, consultados el 7 de octubre de 2026).

Direcciones dentro de un QR: la URI bitcoin:

El QR de «Recibir» suele llevar una URI bitcoin: y no la dirección suelta. Con importe y etiqueta tiene esta forma, con la dirección del vector de BIP-173 (ejemplo ficticio, no envíes fondos): bitcoin:bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4?amount=0.001&label=Ejemplo. El importe va en BTC decimal, con punto y sin comas.

BIP-21 (2012) definió este formato y hoy figura como Closed, sustituido por BIP-321 (Complete, asignado el 15 de noviembre de 2024). La ABNF estricta de BIP-21 solo contemplaba Base58 y en la práctica las billeteras ya usaban bech32. BIP-321 admite bech32 y bech32m y permite dejar la dirección vacía si hay otra instrucción de pago, como una factura Lightning en el parámetro lightning= (más en facturas Lightning). Dice también que una billetera no debe actuar sobre una URI sin autorización del usuario. BIP-321 no fija qué instrucción tiene prioridad.

Direcciones que se pueden reutilizar sin daño

Pedir una dirección nueva a cada pagador exige hablar con el receptor cada vez. Hay dos estándares para tener un identificador fijo. Las direcciones de Silent Payments (BIP-352, formato bech32m con prefijo sp) lo dan sin reutilizar nada en la cadena. Los códigos de pago de BIP-47 también evitan reutilizar la dirección de cobro, pero cada pagador nuevo manda antes, una sola vez, una transacción de notificación a una dirección fija del receptor, que así se reutiliza a la vista (BIP-47, estado Deployed, consultado el 2026-10-07). Cómo funcionan está en Silent Payments.

Qué significa esto para ti

Trata cada dirección como un destino de un solo uso y deja que la billetera genere una nueva en cada cobro. Si te pasan una dirección por un canal que no controlas, confírmala por otro y compárala completa en la pantalla de tu hardware wallet antes de firmar. Una pantalla que muestra la misma dirección que has verificado vale más que cualquier checksum.

Y si una dirección te sale «inválida», no la corrijas a ojo. Pide que te la envíen otra vez.