Tipos de script y formatos de dirección

Una dirección es una codificación legible para las personas de un script de bloqueo. Su formato indica al analista qué tipo de script se usa, lo que permite acotar el software de billetera y la época de la que procede, y determina qué información se hará pública cuando se gasten las monedas. Leer los formatos con fluidez y saber qué ocultan o revelan multisig y Taproot son conocimientos básicos para cualquiera que trabaje con datos UTXO.

Del script a la dirección

Las direcciones no aparecen en la cadena. Lo que la cadena almacena es el scriptPubKey; los exploradores y decodificadores lo convierten en una dirección para mostrarlo. Cada tipo de script estándar se corresponde con una codificación y un prefijo reconocible (los scripts se analizan en detalle en la lección Transacciones de Bitcoin sin procesar):

Las redes de prueba usan prefijos diferentes (m o n para P2PKH, 2 para P2SH, tb1 para SegWit), por lo que es fácil detectar una dirección de red de prueba aislada en un conjunto de datos. Algunos scripts más antiguos, como los outputs de pago a clave pública de los primeros años de la minería y multisig sin envolver, no tienen una dirección estándar: los exploradores muestran la clave pública o una etiqueta sintética, y los almacenes de datos pueden dejar vacía la columna de direcciones. Una consulta que filtre por address IS NOT NULL los descarta sin indicarlo.

Base58Check

Las direcciones heredadas usan Base58Check. El codificador toma un byte de versión, agrega la carga útil de 20 bytes (un HASH160 de una clave pública o de un script), calcula una suma de verificación y escribe el resultado con un alfabeto de 58 caracteres que excluye los caracteres fáciles de confundir 0, O, I y l.

byte de versión   00                -> P2PKH de la red principal, por lo que la cadena empieza con "1"
carga útil        HASH160 de 20 bytes de una clave pública
suma de verificación primeros 4 bytes de SHA-256(SHA-256(version || payload))
codificado        Base58 de los 25 bytes -> 1Fx3…9qLm

Cada byte cero inicial se convierte en un 1 inicial; por eso todas las direcciones P2PKH empiezan con ese carácter. Base58Check distingue entre mayúsculas y minúsculas, y la suma de verificación de 4 bytes hace que casi siempre se rechace una dirección mal escrita. Para los analistas, el byte de versión es la clave de clasificación: 0x00 significa P2PKH, 0x05 significa P2SH y cualquier otro valor corresponde a otra red o a otra moneda.

Bech32 y bech32m

Las direcciones SegWit nativas usan bech32, definido en BIP-173. Una cadena bech32 tiene tres partes: una parte legible para las personas (bc para la red principal, tb para la red de prueba), el separador 1 y una parte de datos escrita con un alfabeto de 32 caracteres que excluye 1, b, i y o. El primer carácter de datos es la versión witness (q es la versión 0, p es la versión 1), seguido del programa witness y una suma de verificación de 6 caracteres.

bc1q…7k3f            42 caracteres
hrp        bc        -> Bitcoin de la red principal
separador  1
versión    q = 0     -> SegWit v0, por lo que la suma de verificación debe ser bech32
programa   20 bytes  -> P2WPKH (un programa de 32 bytes sería P2WSH)
suma de verificación últimos 6 caracteres

Bech32 se escribe todo en minúsculas (se permiten mayúsculas para códigos QR, pero los decodificadores deben rechazar la combinación de mayúsculas y minúsculas), tiene una longitud máxima de 90 caracteres y su suma de verificación garantiza la detección de cualquier error que afecte hasta cuatro caracteres. Tiene un defecto: cuando una cadena termina en p, insertar o eliminar caracteres q justo antes de esa p puede dejar válida la suma de verificación. En la versión 0, las longitudes estrictas del programa (20 o 32 bytes) hacen que esto sea en gran medida inocuo. Las versiones posteriores permiten otras longitudes, por lo que BIP-350 introdujo bech32m, idéntico salvo por la constante que se usa en la suma de verificación (0x2bc830a3 en lugar de 1). Las direcciones de la versión 0 siguen usando bech32; las versiones de la 1 a la 16, incluido Taproot, usan bech32m. Un decodificador debe rechazar una dirección de la versión 1 con una suma de verificación bech32 y una dirección de la versión 0 con una suma de verificación bech32m.

Aspectos prácticos para los procesos de datos: no clasifique basándose únicamente en «empieza con bc1»; lea el cuarto carácter (q o p) y la longitud. Los analizadores sintácticos escritos antes de 2021 pueden rechazar direcciones bc1p válidas o tratarlas como errores, y un proceso de datos que descarte las filas que no puede analizar subestimará la actividad de Taproot sin advertencia alguna.

Qué revelan los formatos sobre las billeteras

Los formatos de dirección reflejan la historia de las billeteras, por lo que aportan información sobre el software que hay detrás de ellas:

• 1… (P2PKH): billeteras antiguas, servicios que solo admiten formatos heredados y algunas billeteras de exchange con una larga trayectoria. La actividad P2PKH actual suele apuntar a software antiguo o personalizado.
• 3… (P2SH): ambiguo hasta que se gasta. Puede ser una billetera multisig o una billetera de una sola clave que use SegWit anidado (P2WPKH envuelto en P2SH), una opción predeterminada común alrededor de 2017–2019.
• bc1q… (SegWit v0): el tipo de dirección de recepción predeterminado de la mayoría de las billeteras convencionales en los últimos años. P2WSH (62 caracteres) suele indicar multisig u otro script personalizado.
• bc1p… (Taproot): billeteras que adoptaron Taproot después de su activación en el bloque 709.632, en noviembre de 2021, además de herramientas para inscripciones y tokens que dependen de este formato.

Cuando se gasta un output 3…, el script de canje aparece en la entrada y resuelve la ambigüedad: un script de canje compuesto por 0014 más 20 bytes es P2WPKH anidado; 0020 más 32 bytes es P2WSH anidado; y uno que termina en ae (OP_CHECKMULTISIG) es multisig clásico.

Los tipos de script también se combinan dentro de las transacciones. Si todas las entradas son P2WPKH y los dos outputs son uno P2WPKH y otro P2SH, es más probable que el output que coincide con el tipo de las entradas sea el cambio. El tipo de dirección es una de varias huellas de la billetera, junto con la versión de la transacción, el tiempo de bloqueo y los valores de secuencia, y la codificación de la firma; la lección Heurísticas para detectar el cambio explica cómo combinarlas y cuánta confianza merecen.

Multisig y su huella

Multisig clásico usa OP_CHECKMULTISIG dentro de un script de canje P2SH o de un script witness P2WSH. La política permanece oculta mientras los fondos no se gasten (solo hay un hash en la cadena), pero se hace totalmente pública en el primer gasto. Una entrada P2WSH de 2 de 3 decodificada se ve así:

witness[0]  (vacío)            -- elemento ficticio requerido por OP_CHECKMULTISIG
witness[1]  3044…01            -- primera firma (DER, byte sighash 01)
witness[2]  3045…01            -- segunda firma
witness[3]  5221…21…21…53ae    -- OP_2 <key1> <key2> <key3> OP_3 OP_CHECKMULTISIG

En el script witness, 52 es OP_2 (se requieren dos firmas), cada 21 inserta una clave pública comprimida de 33 bytes, 53 es OP_3 (tres claves) y ae es OP_CHECKMULTISIG. Un gasto revela el umbral, las tres claves públicas y cuáles dos claves firmaron.

Esta huella aporta evidencia valiosa. Los custodios suelen aplicar políticas distintivas (2 de 3, 3 de 5) para el almacenamiento en frío, y la misma clave pública en muchos scripts multisig vincula esas direcciones con un titular de clave de forma mucho más fiable que las heurísticas de comportamiento. Muchas billeteras ordenan las claves lexicográficamente (BIP-67), lo que también constituye una pequeña huella identificadora.

Taproot y privacidad

Taproot combina tres elementos. BIP-340 define las firmas Schnorr en la misma curva secp256k1: firmas fijas de 64 bytes y claves públicas «x-only» de 32 bytes. BIP-341 define el output: OP_1 seguido de una clave Q de 32 bytes, donde Q = P + t·G, P es una clave interna y el ajuste t se compromete con P y con la raíz de Merkle de un árbol opcional de scripts alternativos. BIP-342 define las reglas de script dentro de ese árbol y reemplaza OP_CHECKMULTISIG por OP_CHECKSIGADD.

Un output Taproot se puede gastar de dos maneras, que revelan cantidades de información muy distintas:

En la ruta de clave, una billetera de una sola clave, un grupo de n de n que use agregación de claves (MuSig2) y un esquema de firma por umbral producen lo mismo: una firma para una clave. La ruta de script solo revela la hoja utilizada; las ramas no utilizadas permanecen ocultas, aunque la longitud de la ruta de Merkle revela algo sobre el tamaño del árbol, lo que, como señala el propio BIP-341, puede ayudar a agrupar direcciones.

Para los analistas, Taproot elimina la huella multisig descrita anteriormente cuando se usa la ruta de clave, de modo que las políticas de custodia se vuelven invisibles. No oculta los importes, el grafo de transacciones ni los tiempos; y, aunque su adopción es moderada, el formato bc1p en sí es distintivo. Los gastos por la ruta de script también pueden incluir inscripciones: desde 2023, se han usado witnesses grandes con un «sobre» OP_FALSE OP_IF … OP_ENDIF para insertar imágenes y datos de tokens, un patrón que conviene filtrar al analizar pagos.

Enfoque del examen: correspondencia entre prefijos y longitudes y tipos de script (1, 3, bc1q de 42 y 62 caracteres, bc1p de 62); estructura de Base58Check (byte de versión, suma de verificación de doble SHA-256 de 4 bytes, versión 0x00 frente a 0x05); estructura de bech32 (hrp, separador 1, carácter de versión witness, suma de verificación de 6 caracteres) y el cambio de BIP-350 a bech32m para la versión witness 1 y superiores; por qué «empieza con bc1» no basta para clasificar; cómo un output P2SH gastado se resuelve como SegWit anidado o multisig; qué revela un gasto multisig clásico; gastos Taproot por la ruta de clave frente a la ruta de script, Q = P + t·G y el bloque de control de 33 + 32m; qué oculta Taproot y qué no.