comprensión bech32 Direcciones / BIP173 pregunta

Estoy tratando de entender el código del BIP173 . Leí el BIP, los enlaces a RFC3548 o z-base-32, la propuesta base32 de Mark Friedenbach y algunas publicaciones aquí.

P1: ¿cómo interpretar el manejo de scripts?

Pensé entender que bech32 es una representación de una dirección (que codifica un hash de una clave pública) y no tiene nada que ver con las secuencias de comandos. Me confundí, en la sección de ejemplo dice:

Todos los ejemplos usan la clave pública 0279BE66... ​​Los ejemplos de P2WSH se usan <key OP_CHECKSIG>como script.

En un tx estándar, tendría el sigscript con la firma y, por ejemplo, una clave pública. Entonces, para el tx de gasto, se verifica que la clave pública coincida con la firma. ¿Es lo mismo cierto para una dirección bech32 (además de estar en la sección de testigos)? ¿Hay algún ejemplo con un tx multisig con solo direcciones bech32?

P2: ¿Qué es la línea "GEN = [0x3b6a57b2 ..."?

En la sección Especificación/Suma de comprobación dice:

def bech32_polymod(values):
  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
  ...

Me pregunto, ¿qué hacen estos valores, de dónde vienen? También investigué el código C, pero no hay más explicaciones. ¿Dónde puedo encontrar su significado?

La elección de valores se describe mucho mejor en la implementación de bitcoin de bech32 aquí, vale la pena leer: github.com/bitcoin/bitcoin/blob/master/src/bech32.cpp
Estoy respondiendo a la primera pregunta a continuación. Creo que la segunda pregunta no está relacionada y probablemente debería pasar a un hilo separado.
Gracias, la segunda pregunta se responde actualmente con sus comentarios (?) en el archivo cpp, vinculado por MeshCollider. Si es necesario, levantaré otro. Ahora leyendo a través de la siguiente :-)

Respuestas (1)

¿Cómo interpretar el manejo de scripts?

Lo que te estás perdiendo es que BIP173 no es una forma de codificar claves públicas o scripts. Es una forma de codificar las salidas de transacciones segwit. Lo que esos resultados son y significan está actualmente en BIP141 y BIP143, pero puede cambiar con el tiempo, sin que BIP173 cambie.

Todas las salidas de transacciones de segwit (actuales y futuras) tienen la siguiente estructura:

  • un solo código de operación entre OP_0 y OP_16 (cuyo valor numérico es lo que llamamos la versión testigo)
  • una inserción de una matriz de bytes entre 2 y 40 bytes (que llamamos el programa testigo).

BIP173 simplemente codifica un número de versión testigo y un programa testigo. Nada más y nada menos. No le importa lo que esas cosas significan.

Actualmente hay 2 tipos de salidas nativas de segwit definidas:

  • P2WPKH: pagar para presenciar hash de clave pública. La versión testigo es 0 y el programa testigo es el RIPE160(SHA256(pubkey)) de 20 bytes.
  • P2WSH: hash de script de pago para presenciar. La versión testigo es 0 y el programa testigo es SHA256 (script) de 32 bytes.

Las direcciones de Segwit, tal como se definen en BIP173, permiten codificar los dos tipos anteriores, pero también todos los posibles tipos de salida de testigos futuros, ya que simplemente codifican un número de versión y bytes de programa, sean los que sean.

Algunos de los ejemplos en el BIP usan versiones de testigos reales y programas de esos dos tipos, y para mayor claridad, se enumeran las claves y los scripts. Pero a BIP173 realmente no le importa lo que son.

Para saber cómo se realizan los pagos a claves públicas y scripts multisig en segwit, consulte BIP141 y BIP143.