Respuesta Directa
Compare los formatos de direcciones legacy, SegWit anidado, SegWit nativo y Taproot, prefijos, compatibilidad y límites de seguridad.
Dos direcciones de Bitcoin pueden recibir BTC y aún así crear estructuras de transacción diferentes por debajo. Una dirección de red principal que comienza con 1, una que comienza con 3, una bc1q dirección y una bc1p dirección pueden ser destinos válidos, pero no necesariamente representan el mismo script, codificación o condición de gasto futuro.
Esa diferencia es fácil de pasar por alto porque la billetera presenta una dirección como una sola cadena. Debajo de ella, la dirección le dice al software cómo construir una salida de transacción. Una vez que esa salida se confirma, se convierte en un UTXO que luego debe gastarse de acuerdo con las reglas del script codificadas por esa salida.
La pregunta práctica no es simplemente “¿Qué prefijo es más nuevo?” Es si la dirección pertenece a la red de Bitcoin prevista, qué tipo de salida representa, si el software de envío admite ese formato, y qué puede—y no puede—decirle la dirección antes de autorizar un pago.
Qué representa una dirección de Bitcoin
Una dirección de Bitcoin no es una cuenta en el sentido bancario. No contiene bitcoin, no tiene una clave privada ni proporciona una vista completa del saldo de una billetera. Es una codificación legible por humanos que ayuda a una billetera a construir una salida de transacción particular.
La relación simplificada es:
Dirección de Bitcoin
↓
Decodificación de dirección
↓
scriptPubKey
↓
Salida de transacción
↓
UTXO confirmado
↓
Condición de gasto futuroCuando envías bitcoin, la billetera no mueve un objeto de una cadena de dirección a otra. Consume UTXOs existentes como entradas de transacción y crea nuevas salidas. La dirección de destino proporciona la información necesaria para construir una de esas salidas.
Por eso el formato de dirección importa técnicamente. Una dirección P2PKH conduce a un script de salida diferente que una dirección P2WPKH. Una salida Taproot P2TR es diferente nuevamente. Esas salidas pueden representar bitcoin gastable, pero las condiciones y la serialización utilizadas cuando se gastan no son idénticas.
La dirección no es la clave privada
La clave privada permanece separada de la dirección. Una billetera utiliza material de clave privada para crear la firma o los datos de testigo requeridos por la condición de gasto. Publicar una dirección de recepción no publica la clave privada.
Lo contrario también es importante: ver una dirección no prueba que una persona en particular controle la clave correspondiente. El análisis de blockchain puede observar transacciones y salidas, pero una cadena de dirección por sí sola no es evidencia de identidad.
Por qué existen varios formatos
Bitcoin tiene múltiples formatos de dirección porque el sistema de transacciones evolucionó manteniendo compatibilidad con salidas más antiguas. Los nuevos formatos no reemplazaron las salidas antiguas en la blockchain. En cambio, introdujeron formas adicionales de expresar condiciones de gasto.
Los cuatro formatos que la mayoría de los usuarios encuentran en la red principal de Bitcoin son:
- Legacy P2PKH, comúnmente mostrado con una dirección que comienza con
1. - P2SH, comúnmente comenzando con
3; SegWit anidado es un uso importante de P2SH, pero no el único. - Native SegWit, codificado con Bech32 y comúnmente comenzando con
bc1qpara la versión de testigo 0. - Taproot, codificado con Bech32m y comenzando con
bc1ppara la versión de testigo 1 salidas P2TR.
El cambio importante no es la apariencia de la cadena. Es lo que la dirección decodificada le dice a la billetera que coloque en la nueva salida.
Tipos de direcciones de Bitcoin comparados
| Nombre común | Prefijo de red principal | Codificación | Salida típica | Qué te dice el prefijo |
|---|---|---|---|---|
| Legado | 1 | Base58Check | P2PKH | Familia de byte de versión para una dirección de hash de clave pública de red principal |
| P2SH (incluido SegWit anidado) | 3 | Base58Check | P2SH; SegWit anidado es una posible construcción de script de redención | El destino es P2SH, no el script de redención exacto dentro de él |
| Native SegWit | bc1q | Bech32 | Testigo v0, comúnmente P2WPKH o P2WSH | Destino Bech32 de versión de testigo 0 en red principal |
| Taproot | bc1p | Bech32m | P2TR | Destino Taproot de versión de testigo 1 en red principal |
Esta tabla es útil para la identificación, pero el prefijo no es una descripción completa del comportamiento de gasto futuro. El ejemplo más claro es una 3... dirección: identifica P2SH, pero P2SH puede comprometerse con muchos scripts de redención. SegWit anidado es solo una posibilidad.
Direcciones P2PKH heredadas
Pago heredado a hash de clave pública, o P2PKH, es el formato de dirección más asociado con el software de billetera Bitcoin temprano. En la red principal, estas direcciones Base58Check normalmente comienzan con 1.
La dirección representa un hash de una clave pública. Cuando una billetera paga a ese destino, crea un script de bloqueo P2PKH que requiere una firma válida y la clave pública correspondiente cuando se gasta la salida.
OP_DUP
OP_HASH160
<20-byte public-key hash>
OP_EQUALVERIFY
OP_CHECKSIGLa dirección visible no es, por lo tanto, el script en sí. La billetera decodifica la dirección Base58Check, extrae la versión y la carga útil, y construye el scriptPubKey apropiado.
Las salidas P2PKH siguen siendo salidas de Bitcoin válidas. “Heredado” no significa inválido o automáticamente inseguro. La distinción se vuelve relevante al comparar la estructura de transacciones: gastar una salida P2PKH tradicional coloca los datos de desbloqueo en el script de entrada en lugar de usar la serialización de testigos SegWit.
Esa diferencia puede aumentar el peso de la transacción en comparación con los gastos de clave SegWit comunes. No significa que un pago P2PKH tenga automáticamente una tarifa particular. El número de entradas, el número de salidas, la tasa de tarifa seleccionada y el resto de la transacción firmada aún determinan el costo final.
P2SH y SegWit anidado
Pago a hash de script, o P2SH, movió parte de la lógica de gasto detrás de un hash. Las direcciones P2SH de la red principal usan Base58Check y normalmente comienzan con 3.
Una salida P2SH estándar coloca el hash del script de redención en el script de bloqueo:
OP_HASH160
<20-byte script hash>
OP_EQUALEl script de redención completo se proporciona solo cuando se gasta la salida. Esto creó una herramienta de compatibilidad importante cuando se introdujo SegWit: un programa de testigos SegWit podía colocarse dentro de un script de redención P2SH, permitiendo que un remitente que entendiera las direcciones P2SH ordinarias pagara una salida que luego se gastaría usando las reglas de SegWit.
Una construcción común de una sola clave se llama P2SH-P2WPKH:
Dirección P2SH
↓
hash de redeemScript
↓
redeemScript contiene un programa de testigos P2WPKH
↓
la firma y la clave pública se proporcionan a través de los datos de testigos al gastarUn prefijo 3 no prueba SegWit
Este es uno de los límites más importantes de la identificación visual de direcciones. Una dirección que comienza con 3 te dice que el destino usa la versión de dirección P2SH de mainnet. No revela el script de redención completo antes de que se gaste la salida.
P2SH existía antes de SegWit y puede envolver otros scripts. Tratar cada 3... dirección como “una dirección SegWit” es por lo tanto demasiado amplio.
Límite técnico: el prefijo identifica el formato de dirección externo. No prueba el script exacto oculto detrás de un hash P2SH.
SegWit nativo y bc1q
SegWit nativo elimina el envoltorio de compatibilidad P2SH y representa el programa de testigos directamente. BIP 173 introdujo la codificación Bech32 para direcciones SegWit nativas.
En la mainnet de Bitcoin, la parte legible por humanos es bc. La versión de testigo 0 produce direcciones comúnmente reconocibles por el comienzo bc1q.
Dos salidas comunes de versión de testigo 0 son:
- P2WPKH: un programa de testigos de 20 bytes comúnmente utilizado para pagos de billetera de una sola clave.
- P2WSH: un programa de testigos de 32 bytes que se compromete con un script de testigos.
La dirección en sí misma le da a la billetera la versión y el programa de testigos. Para la versión de testigo 0, los scripts de salida comunes tienen estas formas:
P2WPKH: OP_0 <20-byte key hash>
P2WSH: OP_0 <32-byte script hash>La salida contiene directamente el programa de testigo en lugar de un envoltorio P2SH. Cuando se gasta el UTXO, la firma o los datos de script requeridos por el programa de testigo se suministran en el testigo de la transacción en lugar de en un scriptSig tradicional estilo P2PKH.
Bech32 también cambia la detección de errores
Bech32 no es meramente un alfabeto diferente. Incluye una suma de verificación diseñada para esta familia de direcciones y separa la parte legible por humanos de la red de los datos de testigo codificados.
Las cadenas Bech32 no deben mezclar caracteres en mayúsculas y minúsculas. Las billeteras normalmente muestran las direcciones Bech32 de la red principal de Bitcoin en minúsculas. Una codificación completamente en mayúsculas puede ser válida según la especificación, pero la mezcla de mayúsculas y minúsculas es inválida.
Taproot y bc1p
Taproot introdujo las salidas pay-to-Taproot, o P2TR. P2TR utiliza la versión de testigo 1 con un programa de testigo de 32 bytes. En la red principal de Bitcoin, la dirección resultante comienza con bc1p.
La versión de testigo 1 y posteriores utilizan Bech32m en lugar de la suma de verificación Bech32 original. BIP 350 introdujo este cambio después de que se identificara una debilidad en el uso del comportamiento de la suma de verificación Bech32 original para versiones de testigo más nuevas.
Esto da una regla de identificación práctica:
bc1q... → versión de testigo 0 → Bech32
bc1p... → versión de testigo 1 P2TR → Bech32mEl script de bloqueo P2TR correspondiente usa la versión de testigo 1 y una clave de salida Taproot de 32 bytes:
OP_1 <32-byte Taproot output key>Una salida P2TR se compromete con esa clave de salida Taproot. Posteriormente se puede gastar a través de la ruta de clave o, si se comprometió un árbol de scripts, a través de una ruta de script revelada válida.
La dirección no revela qué ruta se usará finalmente. Ver bc1p te dice que la salida es P2TR. No te dice si el gastador futuro usará una firma de ruta de clave o revelará una ruta de script.
Lo que los prefijos de Bitcoin realmente te dicen
Los prefijos son útiles porque permiten que una persona identifique rápidamente la familia de direcciones y la red probables. Deben tratarse como una verificación inicial, no como una validación completa.
| Ejemplo de inicio | Significado probable en mainnet | Lo que no prueba |
|---|---|---|
1... | Dirección P2PKH de mainnet | Propietario, saldo o identidad del destinatario |
3... | Dirección P2SH de mainnet | Que el script de canje es SegWit anidado |
bc1q... | Dirección nativa de versión de testigo 0 | Si es P2WPKH o P2WSH solo por el prefijo |
bc1p... | Dirección P2TR con testigo versión 1 | Qué ruta de gasto Taproot se utilizará más adelante |
El prefijo tampoco puede autenticar a la persona que te dio la dirección. Una dirección perfectamente codificada y con suma de verificación válida aún puede pertenecer al destinatario equivocado.
La red viene antes que el tipo de dirección
Antes de elegir entre Legacy, SegWit o Taproot, confirma que la dirección pertenece a la red de Bitcoin que pretendes usar.
Las direcciones de la familia Bech32 hacen esto visible a través de su parte legible por humanos. BIP 173 define bc para la red principal de Bitcoin y tb para direcciones de testnet de Bitcoin. La parte legible por humanos es, por lo tanto, parte de la validación de la red, no decoración.
Las familias de direcciones Base58Check también usan diferentes bytes de versión entre la red principal y las redes de prueba, aunque la diferencia es menos obvia para un usuario que solo mira la cadena.
Una billetera debería rechazar una combinación de red/tipo de dirección no compatible, pero la responsabilidad final sigue siendo confirmar la red mostrada por la aplicación de envío. El reconocimiento del formato de dirección no sustituye la verificación de la red.
Para el contexto más amplio de la transacción (entradas, salidas, confirmaciones y la capa base de Bitcoin), usa la referencia de la red Bitcoin.
Tipo de dirección y tarifas de transacción
Es común escuchar que una dirección de Bitcoin más nueva es “más barata”. Esa afirmación es direccionalmente útil en algunas comparaciones, pero demasiado simple para usarse como regla de tarifas.
La dirección elegida por un destinatario afecta el tipo y el tamaño serializado de la salida creada hoy. Más importante aún, cuando esa salida se gasta más tarde, su tipo de script afecta la estructura de la entrada de transacción correspondiente.
SegWit también cambia la contabilidad del Weight de la transacción porque los bytes de testigo se ponderan de manera diferente a los bytes que no son de testigo. Por lo tanto, un gasto de clave Native SegWit común tiene un perfil de Weight diferente al de un gasto P2PKH Legacy comparable. Eso afecta el tamaño virtual cuando se gasta el UTXO, pero aún así no fija la tarifa total de antemano.
La misma cantidad de BTC puede llevar a costos futuros diferentes
Considera a dos usuarios que cada uno recibe la misma cantidad de bitcoin. Uno recibe una salida P2PKH y el otro recibe una salida P2WPKH. El valor es idéntico. La estructura de entrada futura no lo es.
Cuando esos UTXOs se gastan más tarde, sus datos de desbloqueo se serializan de manera diferente. Eso cambia el Weight de la transacción y, por lo tanto, el tamaño virtual. A la misma tasa de sat/vB, un vSize diferente significa una tarifa total diferente.
Este es un escenario técnico ilustrativo, no un registro de transacción de usuario ni una afirmación sobre una billetera específica.
El tipo de dirección aún no determina la tarifa final por sí mismo. Una transacción con muchas entradas SegWit eficientes puede ser más grande que una con una sola entrada Legacy. El número de salidas, las firmas, las rutas de script y la tasa de tarifa elegida también importan.
Para la relación completa entre Weight, tamaño virtual y sat/vB, lee cómo funcionan las tarifas de transacción de Bitcoin. Cuando necesites una estimación específica para una transacción en lugar de una comparación conceptual, usa el Calculadora de tarifas de transacción de Bitcoin.
La compatibilidad es una verificación del remitente
Una dirección de Bitcoin válida no es útil para un flujo de pago si la billetera de envío o el servicio de retiro no entiende el formato.
Esta distinción fue especialmente importante durante la adopción de Native SegWit y posteriormente Taproot. La red de Bitcoin podía reconocer el tipo de salida mientras que las aplicaciones más antiguas carecían de soporte para crear ese destino.
Cuando un servicio rechaza una bc1q o bc1p dirección, no altere la dirección manualmente. No elimine caracteres, cambie el prefijo ni lo convierta a través de un sitio web arbitrario. Utilice un formato de dirección que su billetera receptora haya generado realmente y que el remitente admita explícitamente.
Enviar entre formatos no es conversión
No necesita una billetera Legacy para pagar una dirección Legacy ni una billetera Taproot para pagar una dirección Taproot en el sentido de hacer coincidir los formatos de origen y destino. La transacción de envío consume cualquier UTXO compatible que la billetera seleccione y crea una nueva salida para el script de destino.
La pregunta relevante es si el software de envío puede decodificar y construir la salida de destino solicitada.
Una dirección válida aún puede ser incorrecta
Las sumas de verificación detectan ciertos errores de transcripción. No autentican al destinatario previsto.
Si el malware reemplaza una dirección copiada con otra dirección de Bitcoin válida, el reemplazo puede pasar la validación de suma de verificación perfectamente. El formato técnico es válido; el destino es incorrecto.
Por eso “la billetera aceptó la dirección” no es la verificación de seguridad final. La aceptación le indica que el software reconoció un destino válido o admitido. No prueba de dónde proviene la dirección.
Verifique antes de enviar
Un proceso de verificación útil separa la validación de formato de la validación del destinatario.
- Confirma la red. Asegúrate de que la cartera o el servicio esté enviando Bitcoin en la red de Bitcoin prevista y no otro activo o entorno de prueba.
- Lee la familia de direcciones. A
1,3,bc1qobc1pel prefijo te da una pista inicial de formato. - Confirma el soporte del remitente. El servicio de retiro o la cartera debe aceptar explícitamente el formato de destino.
- Verifica el destino a través de un canal de confianza. Compara la dirección completa en una pantalla de confianza cuando sea práctico, en lugar de confiar solo en unos pocos caracteres iniciales y finales.
- Revisa la pantalla final de transacción de la cartera. Confirma el destinatario, el monto, la tarifa de red y cualquier cambio antes de firmar.
- Protege el material privado. La verificación de la dirección de recepción nunca requiere que ingreses una frase semilla o clave privada en un sitio web.
Para transferencias grandes o operativamente sensibles, las organizaciones a menudo agregan procedimientos independientes de verificación de destino. Esos procedimientos son un control operativo, no una propiedad de un formato específico de dirección de Bitcoin.
La Reutilización de Direcciones Es un Tema Aparte
Una dirección de Bitcoin no expira a nivel de protocolo simplemente porque se haya usado una vez. Si la condición de gasto correspondiente sigue siendo controlable, los pagos futuros a la misma dirección aún pueden crear salidas válidas.
Eso no hace deseable la reutilización de direcciones. Reutilizar una dirección de recepción puede facilitar la asociación de transacciones en la cadena de bloques pública y puede reducir la privacidad.
Esta cuestión de privacidad es independiente de si la dirección es P2PKH, P2SH, P2WPKH o P2TR. Un formato de dirección moderno no hace que el uso repetido de la misma dirección visible sea privado.
Los Límites de la Validación de Direcciones
La validación de formato responde una pregunta limitada: si la cadena puede decodificarse como el tipo esperado de destino de Bitcoin bajo las reglas de dirección relevantes. No autentica a la persona que la proporcionó, no prueba la propiedad de una clave privada, no prueba el saldo total de una cartera, no garantiza que un servicio admita el formato, ni determina la tarifa final de la transacción.
Tampoco puede revelar información ocultada deliberadamente por la construcción de la salida. Una dirección P2SH no expone el script de canje completo antes de gastar, y una dirección P2TR no le dice de antemano si el gasto futuro utilizará la ruta de clave o revelará una ruta de script. Trate la decodificación exitosa como una verificación en el proceso de pago, no como una prueba de que cada suposición circundante es correcta.
Elección de un formato de recepción
El valor predeterminado más seguro es utilizar una dirección generada por la billetera que realmente controla en lugar de construir o convertir una dirección manualmente.
Si la billetera receptora ofrece más de un tipo de dirección, utilice el tipo que coincida con la política de script prevista por la billetera y que el remitente pueda decodificar. Una dirección P2WPKH es apropiada cuando la billetera genera intencionalmente un destino de hash de clave de versión de testigo 0. Una dirección P2TR es apropiada cuando la billetera genera intencionalmente un destino Taproot y el remitente lo admite. Los destinos P2PKH o P2SH más antiguos siguen siendo válidos cuando un flujo de trabajo requiere esos formatos.
No seleccione un formato solo porque alguien afirma que es “el más barato”. La salida que crea hoy se convierte en una entrada solo cuando se gasta más tarde, y el costo final de esa transacción futura depende de la estructura completa de la transacción y de la tarifa.
La dirección debe provenir de la billetera receptora. El remitente debe admitirla. La red debe coincidir. Esas tres verificaciones importan más que perseguir un prefijo por sí mismo.
Preguntas frecuentes sobre direcciones de Bitcoin
¿Cuál es la diferencia entre bc1q y bc1p?
bc1q es comúnmente el comienzo de una dirección de versión de testigo 0 de la red principal de Bitcoin codificada con Bech32, como P2WPKH o P2WSH. bc1p identifica una dirección P2TR de versión de testigo 1 en mainnet codificada con Bech32m.
¿Toda dirección de Bitcoin que comienza con 3 usa SegWit?
No. Una dirección de mainnet que comienza con 3 es una dirección P2SH. SegWit anidado puede usar P2SH, pero P2SH puede comprometerse con otros scripts de redención, por lo que el prefijo solo no prueba que la salida sea SegWit anidado.
¿Las direcciones de Bitcoin distinguen entre mayúsculas y minúsculas?
Las direcciones Base58Check usan un alfabeto que distingue entre mayúsculas y minúsculas. Las codificaciones Bech32 y Bech32m no deben mezclar caracteres en mayúsculas y minúsculas; las billeteras de Bitcoin normalmente las muestran en minúsculas. No cambie manualmente el caso de una dirección.
¿Puedo enviar Bitcoin de un tipo de dirección a otro?
Sí, cuando la billetera de envío admite el formato de destino. Una transacción puede gastar un tipo de entrada compatible y crear un tipo de salida compatible diferente. Los prefijos de origen y destino no tienen que coincidir.
¿Caduca una dirección de Bitcoin?
Ninguna regla de protocolo hace que una dirección de Bitcoin normal caduque después de una fecha determinada o después de un pago. Las billeteras a menudo generan nuevas direcciones de recepción porque la reutilización de direcciones puede reducir la privacidad, no porque las direcciones generadas previamente se vuelvan inválidas automáticamente.
¿Qué tipo de dirección de Bitcoin debo usar?
Use una dirección generada por la billetera receptora para la red de Bitcoin y el tipo de script que pretende usar, luego confirme que el remitente admite ese formato. SegWit nativo es común para pagos modernos, mientras que Taproot es apropiado cuando ambos lados admiten P2TR. No transforme manualmente un formato de dirección en otro.
Fuentes técnicas
Las descripciones anteriores de los formatos de dirección se basan en las Propuestas de Mejora de Bitcoin y en la documentación de Bitcoin Core. Estas referencias definen la codificación de direcciones, los programas de testigo y el comportamiento de los scripts; no demuestran la identidad ni la seguridad de una dirección de recepción específica. Para conocer el enfoque general de fuentes de BitcoinToolkit, consulta Fuentes de Datos .
- BIP 13: Formato de dirección para pay-to-script-hash — especifica el formato de dirección P2SH Base58Check.
- BIP 16: Pago a hash de script — define el modelo de gasto P2SH y la evaluación del script de redención.
- BIP 49: Esquema de derivación para P2WPKH-anidado-en-P2SH — documenta la construcción común de SegWit anidado de una sola clave discutida en esta guía.
- BIP 141: Testigo segregado — define programas de testigos, Weight de transacciones y semántica de salida SegWit.
- BIP 173: Formato de dirección Base32 para salidas de testigos nativas v0-16 — introdujo la codificación de direcciones SegWit nativas Bech32.
- BIP 350: Formato Bech32m para direcciones de testigos v1+ — define Bech32m y la regla de suma de verificación para versiones de testigos más recientes.
- BIP 341: Taproot — define las reglas de salida y gasto de Taproot, incluida la versión de testigo P2TR 1.
- Descriptores de salida de Bitcoin Core — documenta descripciones estructuradas de scripts de salida de Bitcoin comunes y expresiones de clave.
Fuentes
¿Encontraste un error? Reportar un problema de contenido o lee nuestro Política de Correcciones.