Direcciones y codificaciones: Base58Check, Bech32, Bech32m

Curiosidad

1. ¿Por qué un solo carácter que cambia en una dirección casi siempre la invalida, pero algunos errores de escritura logran pasar desapercibidos?
2. ¿Cómo puede una cadena de letras y números funcionar como un mapa hacia un script de bloqueo específico sin almacenar ese script en la cadena?
3. ¿Qué puede garantizar Bech32 sobre errores tipográficos que Base58Check solo puede hacer poco probables?

Explorar

1. Una dirección no es un objeto almacenado en el conjunto UTXO; es una codificación amigable para los humanos de un script de salida. La cadena solo almacena bytes, pero el software los traduce a cadenas de texto para que las personas puedan leerlas y escribirlas. Esta capa de traducción debe evitar errores de transcripción, ya que una dirección escrita incorrectamente pero que aún parezca válida puede enviar fondos al lugar equivocado. El diseño original de Satoshi, Base58Check, abordó este problema utilizando un alfabeto de 58 caracteres que omite los caracteres visualmente ambiguos ‘0’, ‘O’, ‘I’ y ‘l’.
2. Base58Check codifica un byte de versión, la carga útil (como un hash de 20 bytes) y una suma de verificación de cuatro bytes. La suma de verificación se deriva de los primeros cuatro bytes del hash doble SHA-256 de los datos anteriores. Las direcciones heredadas Pay-to-Public-Key-Hash (P2PKH) utilizan el byte de versión 0x00, lo que da como resultado cadenas que comienzan con ‘1’. Pay-to-Script-Hash (P2SH) utiliza el byte de versión 0x05, produciendo cadenas que comienzan con ‘3’. Esta estructura permite a las billeteras verificar la integridad antes de aceptar una dirección.
3. Segregated Witness (SegWit), activado en agosto de 2017 en el bloque 481,824, introdujo salidas nativas que requerían un nuevo formato de codificación. Base58Check no era adecuado para las estructuras de datos más largas y los patrones de error específicos de SegWit. Pieter Wuille y Greg Maxwell propusieron Bech32 en BIP-173 (2017). Este utiliza un conjunto de caracteres restringido de 32 caracteres: dígitos y letras minúsculas, excluyendo ‘1’, ‘b’, ‘i’ y ‘o’, siendo ‘1’ reservado como separador. El uso exclusivo de mayúsculas evita ambigüedades y es adecuado para códigos QR.
4. Las direcciones Bech32 comienzan con la parte legible para humanos ‘bc’ y el separador ‘1’, seguidos de datos y una suma de verificación de seis caracteres. Esta suma de verificación se basa en los códigos Bose-Chaudhuri-Hocquenghem (BCH), que son significativamente más robustos que la suma de verificación derivada de SHA-256 utilizada por Base58Check. El código BCH garantiza la detección de cualquier error que afecte hasta cuatro caracteres y, a menudo, permite localizar la posición de los errores tipográficos. Las direcciones nativas SegWit v0 (P2WPKH y P2WSH) utilizan este formato, comenzando con ‘bc1q’.
5. Posteriormente, los desarrolladores identificaron una debilidad en el polinomio original Bech32: la inserción o eliminación de secuencias de caracteres específicas podía dar como resultado una dirección válida pero diferente. Para solucionar esto sin afectar las direcciones v0 existentes, BIP-350 (2020) introdujo Bech32m. Este cambio modifica una constante en el cálculo del checksum para que se detecten este tipo de inserciones y eliminaciones. Las direcciones Taproot (versión SegWit 1), activadas en noviembre de 2021, utilizan Bech32m y comienzan con ‘bc1p’.
6. Las direcciones de Testnet utilizan el prefijo ‘tb1’ en lugar de ‘bc1’. La parte de datos codifica el programa witness: un hash de una clave pública o script para la versión 0 de SegWit, o una clave pública modificada de 32 bytes para Taproot. Cuando el software escanea un código QR o acepta entrada manual, ejecuta la función polymod de BCH para verificar la integridad. Abra un explorador de bloques y localice una dirección de cada tipo: una P2PKH tradicional que comienza con ‘1’, una de SegWit v0 que comienza con ‘bc1q’, y una dirección Taproot que comienza con ‘bc1p’. Anote sus longitudes y prefijos.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• P. Wuille, G. Maxwell, 'SegWit address format' (BIP-173, 2017)
• P. Wuille, 'Bech32m format for v1+ witness addresses' (BIP-350, 2020)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 4
• Bitcoin Wiki, 'Technical background of version 1 Bitcoin addresses'