Scripts estándar: P2PKH y P2SH

Curiosidad

1. ¿Por qué Bitcoin bloquea las monedas en un hash en lugar de en la clave misma?
2. ¿Cómo verifica un script de cuatro líneas la propiedad y la autorización en una sola ejecución?
3. ¿Qué hizo que P2PKH fuera el formato de dirección predeterminado durante más de ocho años en la historia de la red?

Explorar

Parte IPago por hash de clave pública (P2PKH)

1. El bloque de génesis contenía únicamente salidas de tipo Pay-to-Public-Key (P2PK). Estos scripts colocaban la clave pública completa (en 2009, una clave sin comprimir de 65 bytes) directamente en la salida, visible antes de cualquier gasto, lo que hacía que las salidas fueran grandes. P2PKH, también presente en el software original de 2009 y utilizado para pagos a direcciones ordinarias, almacena en su lugar un hash de 20 bytes, ocultando la clave hasta que las monedas se gastan.
2. El script de bloqueo es `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG`. La ejecución comienza con los datos del gastador en la pila: primero la firma y luego, encima, la clave pública. El motor duplica la clave, la hashea utilizando RIPEMD-160(SHA256(clave)) y compara el resultado con el hash almacenado. Si coinciden, `OP_EQUALVERIFY` pasa; de lo contrario, la ejecución se detiene inmediatamente.
3. Una vez que la verificación del hash tiene éxito, `OP_CHECKSIG` verifica la firma ECDSA en relación con la clave pública revelada y los datos de la transacción. Este mecanismo dual asegura que solo el titular de la clave privada correspondiente pueda desbloquear los fondos. El script de salida tiene un tamaño total de 25 bytes, una estructura compacta que se convirtió en la base para las direcciones heredadas que comienzan con ‘1’.
4. P2PKH fue el tipo de salida más común para los pagos ordinarios durante la mayor parte de la historia de Bitcoin, y así se mantuvo durante años después de que se activara SegWit en agosto de 2017, en el bloque 481,824, ya que la adopción del SegWit nativo fue gradual. Su éxito radicaba en su simplicidad y compatibilidad; no requería actualizaciones de consenso más allá de las reglas del protocolo original. Cada nodo podía validar estos scripts de forma independiente sin necesidad de un seguimiento complejo del estado, lo que lo convirtió en el tipo de salida más robusto para transferencias de uso general durante la fase inicial de crecimiento de Bitcoin.
5. El formato de la dirección utiliza la codificación Base58Check, que incluye un checksum de cuatro bytes para detectar errores tipográficos. Un solo carácter escrito incorrectamente casi con certeza hará que el checksum falle, por lo que la billetera rechaza la dirección. Esta redundancia hizo que P2PKH fuera fácil de usar a pesar de su complejidad técnica, cerrando la brecha entre la seguridad criptográfica y la usabilidad humana.
6. Abra un explorador de bloques y localice cualquier transacción cuya entrada haga referencia a una dirección ‘1’. Examine el campo `scriptSig`: contiene la firma seguida de la cadena hexadecimal de la clave pública. Compare esta clave pública con el hash de 20 bytes en `scriptPubKey` de la salida a la que hace referencia. Al aplicar SHA-256 y luego RIPEMD-160 a esa clave, se obtendrá el hash almacenado, lo que confirmará el vínculo.

Parte IIPago por hash de script (P2SH)

7. Antes de 2012, utilizar un script complejo como una multisignatura de cinco firmas requería incluir todo el código de bloqueo directamente en la salida. Esto hacía que la salida fuera grande, y el remitente tenía que pagar la tarifa correspondiente. Además, exponía las claves públicas de cada participante y los requisitos específicos de firma a cualquiera que observara la cadena. El remitente tenía que conocer la estructura exacta del destino antes de enviar, lo que suponía una dificultad para las tesorerías corporativas o las bolsas que necesitaban configuraciones de seguridad flexibles.
8. Gavin Andresen propuso BIP16 a principios de 2012 para resolver este problema. Permitía que la salida contuviera únicamente el digesto HASH160 de un script en lugar del propio script. El script de salida se redujo a 23 bytes, ligeramente menos que los 25 de P2PKH. El remitente ya no necesitaba conocer las condiciones de gasto; simplemente pagaba hacia un hash. La complejidad pasó por completo a la persona que gastaba las monedas.
9. La activación de BIP16 en abril de 2012 fue controvertida. Luke Dashjr propuso una alternativa, BIP17, que utilizaba un opcode y un esquema de codificación diferentes. El debate sobre qué propuesta adoptar se intensificó significativamente dentro de la comunidad de desarrolladores. BIP16 se activó en abril de 2012 tras el apoyo expresado por los mineros, y se convirtió en la forma estándar para encapsular scripts complejos.
10. Gastar una salida de tipo pay-to-script-hash es un proceso en dos etapas. Primero, el gastador coloca su script de canje completo en la pila. El nodo verifica si el HASH160 de ese script coincide con el hash de la salida. Si no coincide, la ejecución falla inmediatamente. Si coincide, el nodo luego ejecuta el script de canje revelado junto con los datos restantes en la pila para verificar las condiciones reales de gasto.
11. El diseño tiene un aspecto problemático: nadie puede verificar el script de canje antes del pago, ya que solo su hash se encuentra en la cadena. Si el software del destinatario crea un script defectuoso, o si dicho script se pierde, las monedas enviadas a esa dirección pueden quedar inutilizables para siempre.
12. Cuando SegWit se activó en agosto de 2017, P2SH sirvió como puente de compatibilidad. Los usuarios podían envolver los nuevos scripts witness dentro de un sobre P2SH, creando direcciones “anidadas” que seguían comenzando con “3”. Las billeteras antiguas que no podían manejar las direcciones bech32 más recientes aún podían enviar dinero a usuarios de SegWit, mientras que los destinatarios conscientes de SegWit obtenían un descuento en las comisiones al realizar transacciones. Hoy en día, aunque se prefiere el uso nativo de SegWit por su eficiencia, P2SH sigue siendo un mecanismo vital para contratos complejos y la compatibilidad con sistemas antiguos.

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.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• Bitcoin Developer Guide, 'Transactions' documentation (bitcoin.org)
• Satoshi Nakamoto, original Bitcoin client source code (2009-2010 commits)
• Gavin Andresen, BIP16: Pay to Script Hash (2012)
• Luke Dashjr, BIP17: OP_CHECKHASHVERIFY (CHV) (2012)
• Bitcoin Developer Guide: Transactions and Scripts