¿Cuáles son las implicaciones de BIP 12 frente a BIP 16 y OP_CODEHASHCHECK?

BIP 12 crea un nuevo código de operación de secuencia de comandos que permite que las secuencias de comandos ejecuten más secuencias de comandos almacenadas en una cadena (como las funciones de evaluación en otros idiomas). No hay mucho debate sobre BIP 12: no se utilizará. Es muy complicado, permite algunos bucles (que Script no debería admitir) y dificulta el análisis de scripts sin ejecutarlos.

Con BIP 16, los scripts pueden ejecutar scripts almacenados en una cadena una vez (no de forma recursiva), y también existen otras restricciones que eliminan todos los inconvenientes de BIP 12 mencionados anteriormente.

CODEHASHCHECK hace lo mismo que BIP 16, pero podría decirse que algunas diferencias técnicas lo hacen más elegante.

Todas estas propuestas están diseñadas para resolver el problema de cómo permitir que los destinatarios elijan qué restricciones colocar en las monedas que reciben en una dirección (autenticación de dos factores, etc.). Actualmente, los remitentes siempre definen las restricciones sobre las monedas enviadas, lo que es un inconveniente en muchos casos.

El mayor inconveniente de OP_EVAL (BIP 12) fue hacer que el sistema de secuencias de comandos utilizado para las transacciones se completara, eliminando así cualquier intento de análisis estático. Esto se consideró un problema muy serio y BIP12 ha sido prácticamente asesinado a tiros y enterrado.

P2SH (BIP 16) pretende ser otro enfoque para el mismo problema de introducir transacciones autorizadas de múltiples claves a nivel de protocolo. Está diseñado específicamente (como lo estaba el sistema de secuencias de comandos original) para no estar completo.

Hubo una animada discusión entre los desarrolladores principales y Luke-Jr, quien propuso usar su propia solución, OP_CODEHASHCHECK, en lugar de P2SH.

Lea la publicación para más detalles.

Hay tres BIP que tienen como objetivo proporcionar la función push-to-script-hash (P2SH):

BIP 12 (OP_EVAL): un nuevo código de operación toma un valor de la pila (desde cualquier lugar) y lo ejecuta como si fuera parte del propio script.

• Desventajas: esto hace que Bitcoin Scripting sea completo (permite bucles) y no se puede analizar estáticamente.
• Ventajas: Puedes hacer cosas que requieren un lenguaje turing-completo en Scripts.

BIP 16: cuando se ve una plantilla de secuencia de comandos mágica, después de que la secuencia de comandos se ejecuta, los clientes también deben ejecutar el elemento de la pila superior.

• Desventajas: Requiere una plantilla de secuencia de comandos con mayúsculas y minúsculas y se comporta de manera diferente a simplemente ejecutarla como una secuencia de comandos. No se puede usar en combinación con el protocolo Bitcoin Script actual, pero no lo desaprueba.
• Ventajas: conserva el estado actual de los scripts, mayormente analizable estáticamente.

BIP 17 (OP_CHECKHASHVERIFY): un nuevo código de operación procesa el script que ya se ha ejecutado y simplemente lo compara con el elemento de la pila superior.

• Desventajas: No se puede usar para evaluar código en ninguna capacidad.
• Ventajas: Analizable estáticamente utilizando exactamente el mismo método que ahora, y solo requiere una adición de código de operación trivial sin reestructurar todo el protocolo de script.

También tenga en cuenta que BIP 17 no impide que BIP 12 o 16 se implementen en el futuro, en caso de que surja alguna otra necesidad de sus capacidades más complicadas.