Pacto: un acuerdo generalmente formal, solemne y vinculante.
Esta palabra se ha convertido en una de las palabras más cargadas en el espacio de Bitcoin. Son lo mejor desde el pan en rodajas. Son lo más peligroso desde la bomba atómica. Realmente no van a hacer nada para escalar bitcoin, pero están bien.
Todos tienen una actitud completamente diferente hacia ellos. Tenemos la facción pro, la facción, la facción ambivalente. Para empeorar las cosas, el pacto es francamente un término muy vago en su descripción de propuestas maduras y concretas al protocolo que se clasificaría como convenios.
Los grados de diferencia entre la funcionalidad de diferentes propuestas que se han presentado son enormes. Algunos de ellos crean espacios de diseño completamente nuevos para lo que es posible construir sobre Bitcoin, mientras que otros estrictamente hablando no agregan ninguna funcionalidad nueva, simplemente optimizan cosas que ya son posibles actualmente con un gran grado de complejidad y gastos generales.
Creemos una nueva definición específica para Bitcoin.
Pacto: Cualquier script que garantice algunos, o todos, de las salidas creadas por una transacción que gasten una entrada con un script de pacto tendrá que adaptarse a ciertos criterios especificados para que la transacción de gasto sea válida de consenso.
Entonces, en términos menos estrictos, si un script bitcoin actualmente restringe OMS puede gastar una moneda exigiendo una prueba de autorización, es decir, una firma criptográfica, o cuando Se puede gastar, es decir, después de que un timelock expire o el gastador puede mostrar la preimagen a un hash, un script de pacto restringe cómo Se puede gastar, es decir, a quién, cuánto de qué persona, etc., un guión de pacto puede incluso restringir una moneda para que deba gastarse a otro guión de pacto.
Esa última parte es el núcleo de lo que ha convertido al pacto en una palabra tan contenciosa. Muchas personas tienen grandes reservas sobre agregar una nueva forma de “bloquear” bitcoins que pueden autopropagarse y garantizar que las monedas futuras estén restringidas de manera similar. Muchas personas les preocupa que esto se use para dañar la fungibilidad o los regímenes de censura del instituto.
Siento que es necesario señalar que ambas cosas se pueden lograr en este momento, sin capacidad de secuencia de comandos de pacto, simplemente utilizando MultiSIG. Cualquier autoridad puede negarse a permitir que los retiros se procesen de los intercambios a menos que sean a una multisig de 2 de 2 donde esa autoridad posee una clave. A partir de ahí, simplemente pueden negarse a firmar transacciones que se envían a direcciones donde no poseen una clave requerida, y establecer cualquier esquema de lista negra o de la lista blanca que deseen opacamente y completamente fuera de la cadena.
Dicho esto, todavía es importante que los usuarios de Bitcoin tengan una comprensión y comprensión de la diferencia de potencia y flexibilidad entre todas las diferentes propuestas de pacto que existen actualmente.
Hay dos cosas centrales que los convenios buscan habilitar para aplicar restricciones a cómo se gastan monedas, introspección y Reenviar datos.
La introspección es la capacidad de inspeccionar diferentes partes de la transacción que se está evaluando mientras intenta gastar una moneda específica. Entonces, por ejemplo, si desea restringir una moneda para que tenga que gastarse en una dirección específica, debe poder comparar la dirección especificada en el script del pacto de la entrada con la dirección especificada en la salida de la transacción que lo gastan. Los códigos de operación que habilitan la introspección son los que nos dan la capacidad de comparar diferentes partes de la transacción de gasto contra las restricciones incluidas en el script que se está evaluando. Cuanto más granular pueda obtener con la introspección sobre qué partes particulares de una transacción puede examinar, más poderoso será.
El transporte de datos hacia adelante está relacionado con la introspección y, en muchos sentidos, una consecuencia de ello, lo que le permite asegurarse de que se lleva a cabo alguna información e incluida en cada nuevo script del pacto para que pueda usarse en la próxima evaluación del script del pacto. Esto se logra mediante el uso de la introspección para restringir ciertas partes de la transacción tan estrechamente que deben incluir los datos exactos deseados o no son válidos. Cuanto más poderosa sea la capacidad introspectiva, más flexible puede llevar los datos hacia adelante y, más flexible, puede usar esos datos.
Esta es solo la primera introducción a una serie de artículos que llegarán en las próximas semanas analizando todas las principales propuestas de pacto que están en un estado maduro, han recibido un interés reciente o son conceptualmente de manera crítica lo suficientemente importante como para que los desarrolladores estén de acuerdo en su utilidad pero que aún no es un diseño concreto. Esto no será 100% completo, pero será relativamente completo. Algunos de ellos tampoco son estrictamente convenios per se, sino que se componen muy bien con ellos.
Estos incluirán:
- CheckTempl cualquiera
- ChecksigFromstack
- Txhash
- Op_Vault
- CheckcontractVerify
- GATO
- Tweakverify
