Formatos de direcciones Bitcoin: Legacy, SegWit y Taproot

El formato de una dirección Bitcoin indica al monedero qué tipo de script de bloqueo debe utilizar para recibir los fondos. En la red principal, las direcciones que empiezan por 1 suelen ser Legacy P2PKH, las que empiezan por 3 suelen pertenecer a P2SH, bc1q identifica normalmente SegWit nativo de versión 0 y las direcciones Taproot usan bc1p con un programa de witness de 32 bytes. El prefijo bc1p por sí solo no demuestra que sea Taproot ni que la dirección sea válida. No son etiquetas distintas para la misma salida: codifican tipos de script, reglas de checksum y capacidades de gasto diferentes. Para un pago nuevo de firma única, utiliza un formato admitido por el monedero receptor y el emisor; SegWit nativo y Taproot son opciones modernas.

Las reglas proceden de los propios estándares de Bitcoin. BIP 173 define Bech32 para las direcciones SegWit nativas de versión 0, mientras que BIP 350 introdujo Bech32m para la versión de witness 1 y posteriores, incluido Taproot. La regla práctica es sencilla: no elijas una dirección solo por su aspecto. Deja que el monedero receptor la genere, verifica la red y la cadena completa y confirma que el servicio emisor admite ese formato.

Resumen de los formatos de direcciones Bitcoin

Los prefijos de la tabla describen direcciones de mainnet en minúsculas con codificaciones válidas y las longitudes de programa requeridas. La tabla sirve para reconocer familias, no sustituye la validación ni autentica un destinatario. El prefijo no demuestra quién controla la dirección ni que el usuario haya escogido la red correcta.

Qué representa realmente una dirección Bitcoin

Una dirección Bitcoin es una codificación legible de información que permite construir la condición de bloqueo de una salida. No es la clave privada ni funciona como una cuenta bancaria con un saldo permanente.

Bitcoin registra salidas no gastadas. Cuando alguien paga a una dirección, la transacción crea una salida con un script que define qué condiciones deben satisfacerse para gastarla. Más adelante, el propietario aporta la firma o los datos de script necesarios. Por eso los formatos de dirección, la gestión de UTXO y las comisiones están relacionados.

La referencia para desarrolladores de Bitcoin explica cómo se forman las direcciones P2PKH y P2SH a partir de bytes de versión, hashes y checksums. En mainnet, P2PKH utiliza el byte 0x00, que suele producir direcciones que empiezan por 1, mientras que P2SH utiliza 0x05, que suele producir direcciones que empiezan por 3. BIP 13 estandarizó este último formato. Ambos codifican un byte de versión, un hash de 20 bytes y un checksum de cuatro bytes: los primeros cuatro bytes de SHA256(SHA256(versión + hash)), seguidos de la codificación Base58.

La expresión “dirección del monedero” puede inducir a error: un mismo monedero puede generar muchas direcciones de recepción y, por privacidad, suele ser preferible rotarlas.

Direcciones Legacy: P2PKH y el prefijo 1

Las direcciones Pay-to-Public-Key-Hash son el formato histórico más reconocido. En la red principal suelen comenzar por 1.

Una salida P2PKH compromete un hash de la clave pública. Para gastarla, el propietario revela la clave pública y aporta una firma válida. Sigue siendo Bitcoin válido: “Legacy” no significa que el formato sea inválido o inseguro por definición.

Su principal desventaja es la eficiencia. Los inputs Legacy no obtienen las ventajas de peso de SegWit. Una transacción que gasta salidas Legacy normalmente consume más peso de bloque que una operación equivalente con SegWit nativo, lo que puede aumentar las comisiones cuando el espacio de bloque está caro.

Legacy sigue siendo útil si un servicio antiguo no acepta formatos más nuevos. Esa compatibilidad debe comprobarse, no suponerse.

P2SH y las direcciones que empiezan por 3

Las direcciones Pay-to-Script-Hash suelen empezar por 3 en mainnet. P2SH permitió que el receptor comprometiera el hash de un script en lugar de obligar al emisor a entender toda la lógica de gasto.

Por eso P2SH se utilizó para configuraciones multisig y otras condiciones complejas. Más tarde también se convirtió en un envoltorio de compatibilidad para SegWit mediante P2SH-P2WPKH y P2SH-P2WSH.

Aquí aparece un error frecuente: una dirección que empieza por 3 no demuestra que sea “SegWit”. El prefijo identifica la familia P2SH; el redeem script determina qué hay detrás.

Si un exchange dice que admite direcciones que comienzan por 3, eso tampoco implica que todas las construcciones posibles estén aceptadas. Utiliza la dirección generada por el monedero receptor y respeta las reglas del servicio emisor.

SegWit nativo: bc1q y Bech32

Segregated Witness cambió cómo se incorporan los datos de witness y cómo se calcula el peso de las transacciones. BIP 141 define SegWit y sus programas de witness. BIP 173 define las direcciones Bech32 para witness de versión 0.

En la red principal utilizan el identificador bc y normalmente empiezan por bc1q.

Para un monedero de firma única, la construcción habitual es P2WPKH. Para scripts más complejos se puede utilizar P2WSH. Ambos pertenecen a witness versión 0. P2WPKH tiene un programa de witness de 20 bytes y una dirección de mainnet de 42 caracteres; P2WSH tiene un programa de 32 bytes y una dirección de 62 caracteres. Las demás longitudes de programa de versión 0 son inválidas.

SegWit nativo está ampliamente soportado y suele ser la opción práctica para transferencias ordinarias porque combina compatibilidad moderna con un menor peso que el gasto Legacy.

Bech32 tiene un checksum de seis caracteres diseñado para detectar errores comunes de transcripción. Su alfabeto de datos en minúsculas es qpzry9x8gf2tvdw0s3jn54khce6mua7l: excluye 1, b, i y o, pero incluye 0 y l. No es la exclusión de 0, O, I y l propia de Base58. Esta restricción se aplica a la parte de datos, no a la parte legible ni al separador. Sin embargo, un checksum correcto no demuestra que la dirección pertenezca al destinatario previsto. Un malware puede sustituir una dirección copiada por otra perfectamente válida.

Taproot: bc1p y Bech32m

Las salidas Pay-to-Taproot, o P2TR, usan witness nativo de versión 1 con un programa de 32 bytes. Sus direcciones de mainnet en minúsculas empiezan por bc1p y tienen 62 caracteres. Un programa de versión 1 de otra longitud no es P2TR; algunas otras longitudes pueden superar la decodificación genérica de direcciones de witness sin recibir las reglas de gasto de Taproot. No utilices una cadena bc1p arbitraria como destino Taproot.

Taproot utiliza witness versión 1. BIP 350 modificó la construcción del checksum para las versiones nuevas y creó Bech32m. La diferencia técnica es importante:

• witness versión 0 utiliza Bech32;
• witness versiones 1 a 16 utilizan Bech32m;
• bc1q y bc1p no son simples variantes ortográficas de la misma dirección.

BIP 341 define el gasto Taproot. Un gasto por clave no revela si existen rutas de script alternativas. Un gasto por script revela el script ejecutado y la prueba de su compromiso, no todos los scripts no utilizados; se distingue de un gasto por clave. Son mejoras limitadas de privacidad de las condiciones de gasto, no anonimato de las transacciones. La documentación de output descriptors de Bitcoin Core refleja las familias con descriptores como pkh(), wpkh(), sh(), wsh() y tr().

Para el usuario la pregunta es más directa: ¿el monedero receptor genera direcciones Taproot y el servicio emisor permite retirar a ellas? Si una de las partes no las admite, SegWit nativo suele ser más sencillo.

Qué formato de dirección Bitcoin deberías usar

Utiliza la dirección que genera el monedero que va a recibir los fondos. No conviertas manualmente una dirección de un tipo a otro.

Proceso recomendado:

1. Confirma que el destino es Bitcoin mainnet y no Bitcoin Cash, Lightning, Liquid u otra red.
2. Abre el monedero receptor y genera una nueva dirección.
3. Si ofrece varios formatos, SegWit nativo suele ser el punto de partida más compatible entre los formatos modernos.
4. Comprueba qué formatos admite el exchange o monedero emisor.
5. Compara el principio y el final y después verifica la dirección completa en un dispositivo de confianza.
6. Para una cantidad importante, valora hacer primero una transferencia pequeña si el coste adicional está justificado.

No se trata de elegir siempre el prefijo más reciente. Se trata de crear una salida que el monedero receptor pueda gastar.

Ejemplo: elegir entre 1, 3, bc1q y bc1p

Imagina que un hardware wallet ofrece cuatro cuentas:

• Legacy: 1...
• SegWit anidado: 3...
• SegWit nativo: bc1q...
• Taproot: bc1p...

Quieres retirar BTC desde un exchange.

Si el exchange acepta bc1q, SegWit nativo suele ser una opción lógica. Evita el envoltorio adicional de P2SH y cuenta con un soporte amplio.

Si el exchange permite retirar a Taproot y el hardware wallet muestra claramente una dirección bc1p en su pantalla, Taproot también es válido. No existe una regla que obligue a usar Taproot para todo pago ordinario.

Si el exchange rechaza bc1q y bc1p, una dirección 3 de SegWit anidado puede aportar compatibilidad. Una dirección Legacy 1 sigue siendo una opción cuando un sistema antiguo lo exige.

Nunca utilices un conversor web aleatorio para “transformar” la dirección y satisfacer un formulario. Si necesitas otro script, genera una dirección de ese tipo dentro de un monedero que controles.

Por qué el formato puede influir en las comisiones

Las comisiones de Bitcoin dependen del peso de la transacción, no de la cantidad de BTC transferida. Normalmente importa más el tipo de inputs que se gastan que el prefijo de la nueva dirección de destino.

SegWit coloca las firmas en datos de witness, que reciben un tratamiento distinto en el cálculo del peso. SegWit nativo evita además el envoltorio P2SH del SegWit anidado. Por ello, gastar inputs P2WPKH suele ser más eficiente que gastar inputs P2PKH comparables.

Taproot también puede ser compacto en el gasto por clave, pero el coste real depende de la composición exacta de inputs y outputs. Prometer un porcentaje fijo de ahorro sería engañoso.

Para entender por qué la selección de inputs cambia las comisiones, consulta la guía de BTC-Pulse sobre selección de monedas, comisiones y privacidad.

El formato no elimina el riesgo de privacidad

Un formato de dirección nuevo no es un escudo de privacidad.

Reutilizar la misma dirección facilita que un observador asocie varios pagos con el mismo destino. Las salidas de cambio y la selección de UTXO pueden crear más señales. BTC-Pulse explica ese problema en salidas de cambio de Bitcoin.

Taproot puede hacer que un gasto simple por clave se vea igual que un gasto cooperativo por clave entre varias partes, pero no hace indistinguibles el gasto por clave y el gasto por script. La privacidad depende también del comportamiento del monedero, la gestión de UTXO, el análisis del grafo de transacciones, la identificación realizada por exchanges y los datos fuera de cadena.

La regla práctica es generar una nueva dirección de recepción cuando el monedero lo permita y evitar publicar una dirección permanente salvo que el caso de uso lo requiera.

Errores frecuentes con direcciones Bitcoin

Confundir Bitcoin y Bitcoin Cash

Algunos servicios soportan ambos activos. Verifica siempre activo y red de forma explícita.

Pensar que todo 3 es SegWit anidado

P2SH es una construcción general. El SegWit anidado es solo uno de sus usos.

Tratar bc1q y bc1p como equivalentes

Representan versiones de witness diferentes y utilizan reglas de checksum distintas. Usa exactamente la dirección generada por el monedero receptor.

Comprobar solo cuatro caracteres

Mirar el principio y el final ayuda, pero un malware puede construir una sustitución convincente. Para transferencias importantes, verifica la dirección completa en la pantalla del hardware wallet o mediante otro canal fiable.

Reutilizar una dirección indefinidamente

Una dirección antigua normalmente sigue siendo gastable si conservas las claves, pero su reutilización perjudica la privacidad y complica la contabilidad.

Enviar sin comprobar compatibilidad

Una dirección puede ser válida para Bitcoin y aun así ser rechazada por un exchange que no haya habilitado ese formato.

¿Las direcciones Bitcoin distinguen mayúsculas y minúsculas?

Las direcciones Base58Check Legacy y P2SH distinguen mayúsculas y minúsculas.

Bech32 y Bech32m están diseñados para usarse en un único caso. La especificación admite cadenas enteramente en mayúsculas o enteramente en minúsculas, pero una cadena Bech32 mezclada es inválida. Los monederos Bitcoin suelen mostrar bc1... en minúsculas.

No cambies manualmente las letras. Copia la dirección tal como aparece en el monedero receptor.

¿El prefijo basta para saber si una dirección es válida?

No.

Además del prefijo deben ser correctos la codificación, el programa de witness o la longitud aplicable, los parámetros de red y el checksum. El límite general de una cadena Bech32/Bech32m es de 90 caracteres, pero las direcciones de witness de mainnet tienen entre 14 y 74. Las versiones de witness van de 0 a 16 y los programas de 2 a 40 bytes, con las longitudes más estrictas de versión 0 y Taproot indicadas antes. Los decodificadores también deben rechazar el relleno de conversión incorrecto y una variante de checksum que no corresponda a la versión de witness. El software del monedero debería validar estos elementos antes de construir la transacción.

Y una dirección técnicamente válida todavía puede pertenecer a la persona equivocada. La validación del formato evita algunos errores; no autentica al destinatario.

¿Se están eliminando los formatos antiguos?

Legacy, P2SH, SegWit nativo y Taproot siguen formando parte del ecosistema de Bitcoin. Que un monedero moderno cambie su formato predeterminado no invalida automáticamente UTXO antiguos.

Lo que cambia es el soporte de software y la preferencia de cada servicio. Un monedero actual puede ofrecer bc1q o bc1p por defecto y un sistema antiguo seguir aceptando únicamente Base58.

Por eso “más nuevo” y “mejor para esta transferencia” no son siempre lo mismo. Compatibilidad, eficiencia, requisitos del script y control del monedero receptor importan más que el prefijo por sí solo.

Lista final antes de enviar BTC

Antes de confirmar:

• verifica que el activo y la red son Bitcoin;
• genera la dirección dentro del monedero de destino;
• confirma que el emisor admite ese formato;
• comprueba la cadena completa en una pantalla de confianza;
• no conviertas direcciones con webs aleatorias;
• utiliza una transferencia de prueba si el importe y el riesgo operativo lo justifican;
• espera las confirmaciones apropiadas antes de considerar definitivo el pago.

El formato indica a Bitcoin cómo podrá gastarse la salida. No indica si el destinatario es legítimo. La seguridad real combina el formato correcto con verificación independiente y una buena gestión de UTXO.

Fuentes

• Bitcoin Developer Reference — Transactions — primary.
• BIP 13 — Address Format for pay-to-script-hash — primary.
• BIP 141 — Segregated Witness — primary.
• BIP 173 — Base32 address format for native v0-16 witness outputs — primary.
• BIP 350 — Bech32m format for v1+ witness addresses — primary.
• BIP 341 — Taproot — primary.
• Bitcoin Core — Output Descriptors — primary.