Hydrologic analysis

El pago-a-hash-de-script (P2SH) fue introducido en 2012 como un poderoso nuevo tipo de transacción que generalmente simplifica el uso de scripts de transacciones complejos. Para explicar la necesidad de P2SH, veamos un ejemplo práctico.

En [ch01_intro_what_is_bitcoin] presentamos a Mohammed, un importador de productos electrónicos en Dubai. La compañia de Mohammed usa la funcionalidad multi-firma de bitcoin de forma exclusiva para sus cuentas corporativas. Los scripts multi-firma son uno de los usos más comunes de las capacidades avanzadas de scripting de bitcoin y son una funcionalidad muy potente. La compañía de Mohammed usa un script multi-firma para todos los pagos de clientes, conocidos en contabilidad como "cuentas por cobrar." Con el esquema multi-firma, cualquier pago hecho por clientes es bloqueado de forma que requieran al menos dos firmas para ser liberados, una de Mohammed y otra de sus socios o un abogado con una clave de backup. Un esquema multi-firma como ese ofrece a la gerencia corporativa controles y la protege de robo, malversación o pérdida.

El script resultante es bastante largo y se ve así:

2 <Clave Pública de Mohammed> <Clave Pública de Socio1> <Clave Pública de Socio2> <Clave Pública de Socio3> <Clave Pública de Abogado> 5 OP_CHECKMULTISIG

Aunque los scripts multi-firma son una funcionalidad potente, son algo engorrosos de usar. Dado el script anterior, Mohammed tendría que comunicar este script a cada comprador antes de realizarse el

pago. Cada cliente tendría que usar un software de cartera bitcoin especial con la habilidad de crear scripts de transacción personalizados, y cada cliente tendría que entender cómo crear una transacción utilizando scripts personalizados. Es más, la transacción resultante tendría que ser alrededor de cinco veces mayor que una transacción de pago común y corriente, ya que este script contiene claves públicas muy largas. La carga de esa transacción extra larga recaería sobre el cliente en forma de tarifas. Por último, un script de transacción grande como este terminaría en la colección de UTXOs en la RAM de cada nodo completo hasta ser gastado. Todos estos problemas hacen el uso de scripts de salida complejos difícil en la práctica.

Pago-a-hash-de-script (pay-to-script-hash, o P2SH) fue desarrollado para resolver estas dificultades prácticas y hacer el uso de scripts complejos tan fácil como un pago a una dirección bitcoin. Con pagos P2SH los scripts de bloqueo complejos son reemplazados con su huella digital, un hash criptográfico. Cuando una transacción que intenta gastar una UTXO es luego presentada, debe contener el script que concuerda con el hash, además del script de desbloqueo. En términos simples, P2SH significa "pagar a un script que concuerde con este hash, un script que será presentado más tarde cuando esta salida sea gastada."

En las transacciones P2SH, el script de bloqueo que es reemplazado por un hash es referenciado como el script de liquidación (redeem script), ya que es presentado al sistema al momento de liquidación en vez de como un script de bloqueo. Script complejo sin P2SH muestra el script sin P2SH y Script complejo como P2SH muestra el mismo script codificado con P2SH.

Table 4. Script complejo sin P2SH

Script de Bloqueo 2 ClavePública1 ClavePública2 ClavePública3 ClavePública4 ClavePública5 5

OP_CHECKMULTISIG Script de Desbloqueo Firma1 Firma2

Table 5. Script complejo como P2SH

Script de Liquidación 2 ClavePública1 ClavePública2 ClavePública3 ClavePública4 ClavePública5 5

OP_CHECKMULTISIG

Script de Bloqueo OP_HASH160 <hash de 20 bytes del script de liquidación> OP_EQUAL

Script de Desbloqueo Firma1 Firma2 script de liquidación

Como puede ver de las tablas, con P2SH el script complejo que detalla las condiciones para gastar la salida (script de liquidación) no es presentado en el script de bloqueo. En cambio, solo su hash se encuentra en el script de bloqueo y el script de liquidación en sí es presentado luego, como parte del script de desbloqueo cuando la salida es gastada. Esto mueve la carga tarifaria y la complejidad del remitente al destinatario (gastador) de la transacción.

Primero, el script multi-firma que usa la compañia de Mohammed para todos sus pagos de clientes entrantes:

2 <Clave Pública de Mohammed> <Clave Pública de Socio1> <Clave Pública de Socio2> <Clave Pública de Socio3> <Clave Pública de Abogado> 5 OP_CHECKMULTISIG

Si los marcadores de posición son reemplazados por claves públicas reales (mostradas aquí como números de 520 bits comenzados en 04) se puede observar que el script se vuelve muy largo:

2 04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984 D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308 EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E632 48B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC1 0F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9 D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1E CED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D1 37AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG

La totalidad de este script puede ser en cambio reemplazado por un hash criptográfico de 20 bytes, aplicando primero el algoritmo de hashing SHA256 y luego el algoritmo RIPEMD160 sobre el resultado. El hash de 20 bytes del script anterior es:

54c557e07dde5bb6cb791c7a540e0a4796f5e97e

Una transacción P2SH bloquea la salida a este hash en vez del script más largo, usando el script de bloqueo:

OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL

el cual, como se puede ver, es mucho más breve. En vez de "pagar a este script multi-firma de 5 claves," la transacción P2SH equivalente es "pagar al script con este hash." Un cliente realizando un pago a la compañía de Mohammed solo necesita incluir este script de bloqueo mucho más corto en su pago. Cuando Mohammed desea gastar esta UTXO, debe presentar el script de liquidación original (cuyo hash bloqueó la UTXO) y las firmas necesarias para desbloquearla, así:

<Firma1> <Firma2> <2 CP1 CP2 CP3 CP4 CP5 5 OP_CHECKMULTISIG>

Ambos scripts son combinados en dos etapas. Primero, el script de liquidación es chequeado contra el script de bloqueo para asegurar que el hash concuerda:

<2 CP1 CP2 CP3 CP4 CP5 5 OP_CHECKMULTISIG> OP_HASH160 <hash de script de liquidación> OP_EQUAL

Si el hash del scritp de liquidación concuerda, el script de desbloqueo es ejecutado por su cuenta para desbloquear el script de liquidación:

<Firma1> <Firma2> 2 CP1 CP2 CP3 CP4 CP5 5 OP_CHECKMULTISIG

Direcciones pago-a-hash-de-script

Otra parte importante de la funcionalidad de P2SH es la habilidad de codificar un hash de un script en una dirección, tal como se define en BIP0013. Las direcciones P2SH son codificaciones Base58Check del hash de 20 bytes de un script, tal como las direcciones bitcoin son codificaciones Base58Check del hash de una clave pública de 20 bytes. Las direcciones P2SH usan el prefijo de versión "5", que resulta en direcciones codificadas en Base58Check comenzadas en "3". Por ejemplo, el script complejo de Mohammed, hasheado y codificado en Base58Check como una dirección P2SH se convierte en 39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw. Ahora Mohammed puede distribuir esta "dirección" a sus clientes y ellos pueden usar prácticamente cualquier cartera bitcoin para hacer un pago sencillo, como si fuera una dirección bitcoin. El prefijo 3 da un indicio de que este es un tipo especial de dirección, uno que corresponde a un script en vez de a una clave pública, pero funciona exactamente de la misma manera que un pago a una dirección bitcoin salvando esa diferencia.

Las direcciones P2SH esconden toda la complejidad de forma que la persona realizando el pago no vea el script.

Beneficios del pago-a-hash-de-script

La funcionalidad de pago-a-hash-de-script ofrece los siguientes beneficios comparado al uso directo de scripts complejos en bloqueo de salidas:

• Scripts complejos son reemplazados por huellas más cortas en la salida de transacción, reduciendo la transacción.

• Los scripts pueden ser codificados como una dirección, de forma que el remitente y la cartera del remitente no necesitan ingeniería compleja para implementar P2SH.

• P2SH desplaza la carga de construir el script al destinatario, no el remitente.

• P2SH mueve la carga en almacenamiento de datos para scripts largos de la salida (la cual se encuentra en la colección de UTXOs) a la entrada (almacenada en la cadena de bloques).

• P2SH mueve la carga en almacenamiento de datos para el script largo del tiempo presente (pago) a un tiempo futuro (cuando es gastado).

• P2SH mueve los costos de tarifas de transacción de un script largo del remitente al destinatario, quien debe incluir el largo script de liquidación para gastarlo.

Script de liquidación y validación isStandard

Antes de la versión 0.9.2 del cliente Bitcoin Core, el pago-a-hash-de-script se encontraba limitado a tipos de scripts de transacciones bitcoin estándar, validados por la función isStandard(). Eso significa que el script de liquidación presentado en la transacción de gasto podía ser tan solo uno de los tipos estándar: P2PK, P2PKH, o multi-firma, excluyendo OP_RETURN y P2SH mismo.

Hacia la versión 0.9.2 del cliente Bitcoin Core, las transacciones P2SH pueden contener cualquier script válido, haciendo al estándar P2SH mucho más flexible y permitiendo experimentación con muchos tipos de transacciones novedosos y complejos.

Nótese que no es posible poner un P2SH dentro de un script de liquidación P2SH ya que la especificación P2SH no es recursiva. Tampoco es posible utilizar OP_RETURN dentro de un script de liquidación ya que OP_RETURN no puede ser liquidado por definición.

Nótese que como el script de liquidación no se presenta a la red hasta el momento de gastar una salida P2SH, si usted bloquea una salida con el hash de una transacción inválida será procesado de todos modos. Sin embargo, no podrá gastarlo ya que la transacción de gasto, la cual incluye el script de liquidación, no será aceptado ya que es un script inválido. Esto crea un riesgo, ya que es posible bloquear bitcoins en un P2SH que no puede ser gastado. La red aceptará la obstrucción P2SH aun si corresponde a un script de liquidación inválido, ya que el hash del script no da ninguna indicación de qué script representa.

WARNING

Los scripts de bloqueo P2SH contienen el hash de un script de liquidación, el cual no da pistas acerca del contenido del script de liquidación mismo. La transacción P2SH será considerada válida y aceptada aun si el script de liquidación no lo es. Es posible bloquear bitcoins accidentalmente de forma que no puedan ser gastados luego.