Este es el primer artículo en un serie El profundo buceo en propuestas de pacto individuales que han alcanzado un punto de madurez que merece un desglose en profundidad.
CheckTempl cualquiera (CTV), presentado por Jeremy Rubin con BIP 119, es la propuesta del pacto más madura y completamente desarrollada, no solo fuera de las propuestas que cubriremos, sino de todas las propuestas de pacto en su totalidad. Como mencioné en el artículo de Introducción a esta serie, hay muchas preocupaciones en el ecosistema con respecto a los convenios que son demasiado flexibles permitiendo cosas que terminan teniendo consecuencias muy perjudiciales para Bitcoin.
CTV fue diseñado específicamente para restringir sus capacidades lo suficientemente estrechamente para evitar cualquiera de esas preocupaciones. Para comprender primero cómo funciona CTV, necesitamos comprender las partes individuales de una transacción de bitcoin.
Esta es una vista de nivel muy alto de una transacción de bitcoin. Tiene entradas o monedas no gastadas (Utxos), y salidas, las nuevas monedas no gastadas que la transacción creará cuando se confirme en un bloque. Hay muchas más piezas por las que pasaremos, pero esta es la vista de nivel más alto de la estructura de una transacción.
Cada transacción también tiene un campo de número de versión para toda la transacción, lo que indica aplicabilidad de nuevas versiones de reglas o características. También está el marcador y el indicador, que se establecen en valores específicos para indicar que la transacción usa SEGWIT. Después de este es el recuento de entradas, el número de entradas en la transacción. Luego vienen las entradas reales.
Cada entrada contiene un TXID de la transacción que creó la moneda no gastada que se gasta, un vout que marca qué salida en esa transacción se está gastando, el tamaño del scriptSig y el scriptSIG, que es el script de desbloqueo que prueba la entrada que se gastan está autorizada por sus reglas de script de ubicación, y finalmente un número de secuencia que se usa para garantizar que la entrada se realiza después de las reglas de tiempo temporal. es decir, la entrada ha existido para un cierto número de bloques o duración de tiempo desde su creación.
El recuento de salida es la siguiente pieza de datos, el número de salidas en la transacción. Después de esto viene las salidas reales, que contienen una cantidad de satoshis asignados a esa salida, el tamaño de scriptpubkey y el scriptpubkey actual, que es el script de bloqueo para esa salida. Por último, el campo Nlocktime aplica un valor de tiempo de tiempo en la marca de tiempo o altura del bloque que se aplica a toda la transacción.
Cada transacción de Segwit también contiene una sección de testigos, donde cada entrada tiene un testigo correspondiente que contiene un recuento de elementos de pila, cuántas cosas se colocarán en la pila de script, un campo de tamaño para cada elemento y el elemento de datos actual para ir a la pila.
Cómo funciona CTV
CTV es un código de operación que permite la forma más básica de introspección y datos hacia adelante que realizan todas las propuestas del pacto. Permite que un script tome un hash de 32 bytes predefinido y examine eso con un hash de la mayoría de los campos de la transacción de gasto. Si el hash derivado de la transacción de gasto actual no coincide con el hash predefinido, la transacción no es válida.
Los campos a los que se compromete son:
- castaño
- nlocktime
- Recuento de insumos
- Un hash de todos los campos de Nequence
- Recuento de salida
- Un hash de todas las salidas
- Índice de entrada (el lugar que tiene la entrada en la transacción, primera entrada, 2nd, and so on.)
Estos son todos los campos comprometidos por el hash CTV, en su totalidad y sin capacidad para elegir y elegir. Este es el grado de introspección que CTV permite: “¿El hash de estos campos en la transacción de gastos coincide con el hash en el script de bloqueo de la entrada que se gasta”, eso es todo. El hash se compromete a esencialmente toda la transacción, excepto las entradas reales. Hay una razón por la que el hash no incluye las entradas. Para bloquear una salida a un hash de 32 bytes con CTV, debe conocer el hash de la transacción que está asegurando que es la única forma de gastarse. La entrada bloqueada con CTV que se gasta tendrá que incluir este hash para ser verificado contra CTV. Que requiere tener el hash de esa transacción antes creas la transacción completa. Eso no es posible.
También puede anidar los scripts CTV, es decir, tener una comisión inicial de script CTV con una transacción con salidas que también incluyen scripts CTV. Esto es lo que permite a CTV “llevar adelante”. Sin embargo, todo lo que lleva adelante en la práctica es cualquier datos contenidos en la cadena de transacciones. Puede hacer esto en teoría con una profundidad infinita, pero está limitado en la práctica a una profundidad finita porque la anidación debe generarse hacia atrás desde el last. Esto se debe a que cada nivel, o “salto”, debe hacer que el hash de la transacción se mueva al siguiente; de lo contrario, no puede crear el script de bloqueo en primer lugar. Si aún no conoce la próxima transacción, no puede generar la anterior.
¿Para qué es útil CTV?
CTV le permite restringir una salida para que solo se pueda gastar, de acuerdo con las reglas de consenso, mediante una transacción exacta predefinida. Algunos de ustedes podrían preguntar cuál es el gran problema, ya podemos firmar transacciones. Si el nivel de introspección es tan limitado que solo puede lograr algo que ya podemos hacer solo firmar, ¿cuál es el valor agregado?
Primero, las transacciones previas firmadas siempre dejan abiertas la posibilidad de que los titulares de clave firmen nuevas transacciones y gasten esas monedas de una manera diferente. Debe confiar en que el titular de la llave no hará esto, o eliminará la clave necesaria para firmar (que también tiene que confiar en ellos). CTV elimina esa confianza por completo. Una vez que se outline la transacción de gasto y la salida bloqueada a ese hash CTV se crea, no hay posibilidad de ser gastado de otra manera, aplicado por el consenso.
Actualmente, la única forma de evitar esa confianza es participar en las transacciones previas a la firma usted mismo utilizando MultiSIG. Entonces puede estar completamente seguro de que, a menos que elija firmar uno usted mismo, no se puede crear otra transacción válida que gaste una moneda de manera diferente. El problema es que cuanto más se involucran las personas, más difícil y poco confiable coordinar a todos para firmar una transacción al mismo tiempo. Pasados tamaños pequeños se convierte en un problema totalmente poco práctico resolver de manera confiable.
CTV ofrece una forma de que las personas sepan que un conjunto de transacciones se compromete sin que todos tengan que conectarse al mismo tiempo para firmarlas. Simplifica enormemente el proceso de coordinación al permitir que todos obtengan la información necesaria a cualquier otra persona siempre que puedan, y una vez que esa persona tiene la información de todos, puede crear la cadena de transacciones CTV sin la participación de nadie, y todos pueden verificar y estar seguros de que el resultado correcto es el único posible.
Eso es increíblemente valioso por sí solo, pero CTV también puede permitir cosas aún más valiosas en combinación con otros códigos de operación, que veremos en el próximo artículo.
Pensamientos de cierre
El CTV es un pacto muy restringido que permite un grado de introspección y datos de avance que es tan limitado que no excede la funcionalidad actual de nada que se pueda hacer con transacciones previas firmadas. La propuesta de valor no está en habilitar una nueva funcionalidad por derecho propio, sino mejorar drásticamente la eficiencia, la escalabilidad y las garantías de seguridad de lo que se puede construir actualmente utilizando transacciones previas al firma. Esto solo es un beneficio masivo para casi todos los protocolo implementado actualmente utilizando transacciones previas a la firma.
Estos son algunos de los proyectos que demuestran cuán completamente desarrollados y explorados se compara este pacto explicit con los demás:
- Un grupo de pago básico ejemplo por stutxo.
- Una bóveda de CTV implementación por James O’Beirnequien pasó a proponer OP_Vault (que todavía hace uso de CTV).
- En su lugar, un puerto de prueba de concepto de la implementación de ARK basada en transacciones previamente firmada desde el segundo por Steven Roose para usar CTV.
- El Lenguaje sapio por Jeremy Rubin Él mismo, un lenguaje de nivel superior para construir contratos con CTV (también respalda el uso de transacciones previas al firmado).
- Tiempo de esperauna propuesta para un diseño de coinpool muy básico de John Legislation.
- Numerosos otros Posibles protocoloscomo contratos de registro discretos optimizados (DLC), canales de rayos no interactivos que una parte podría abrir sin la otra, e incluso formas descentralizadas para que los mineros se unan.
CTV es una propuesta increíblemente madura en este punto, con un alto valor agregado y sin riesgo de permitir que nada impulse las preocupaciones en torno a los convenios. Esto no solo debería considerarse muy seriamente, sino que en mi opinión private debería haberse activado hace años.
Este es el primer artículo en un serie El profundo buceo en propuestas de pacto individuales que han alcanzado un punto de madurez que merece un desglose en profundidad.
CheckTempl cualquiera (CTV), presentado por Jeremy Rubin con BIP 119, es la propuesta del pacto más madura y completamente desarrollada, no solo fuera de las propuestas que cubriremos, sino de todas las propuestas de pacto en su totalidad. Como mencioné en el artículo de Introducción a esta serie, hay muchas preocupaciones en el ecosistema con respecto a los convenios que son demasiado flexibles permitiendo cosas que terminan teniendo consecuencias muy perjudiciales para Bitcoin.
CTV fue diseñado específicamente para restringir sus capacidades lo suficientemente estrechamente para evitar cualquiera de esas preocupaciones. Para comprender primero cómo funciona CTV, necesitamos comprender las partes individuales de una transacción de bitcoin.
Esta es una vista de nivel muy alto de una transacción de bitcoin. Tiene entradas o monedas no gastadas (Utxos), y salidas, las nuevas monedas no gastadas que la transacción creará cuando se confirme en un bloque. Hay muchas más piezas por las que pasaremos, pero esta es la vista de nivel más alto de la estructura de una transacción.
Cada transacción también tiene un campo de número de versión para toda la transacción, lo que indica aplicabilidad de nuevas versiones de reglas o características. También está el marcador y el indicador, que se establecen en valores específicos para indicar que la transacción usa SEGWIT. Después de este es el recuento de entradas, el número de entradas en la transacción. Luego vienen las entradas reales.
Cada entrada contiene un TXID de la transacción que creó la moneda no gastada que se gasta, un vout que marca qué salida en esa transacción se está gastando, el tamaño del scriptSig y el scriptSIG, que es el script de desbloqueo que prueba la entrada que se gastan está autorizada por sus reglas de script de ubicación, y finalmente un número de secuencia que se usa para garantizar que la entrada se realiza después de las reglas de tiempo temporal. es decir, la entrada ha existido para un cierto número de bloques o duración de tiempo desde su creación.
El recuento de salida es la siguiente pieza de datos, el número de salidas en la transacción. Después de esto viene las salidas reales, que contienen una cantidad de satoshis asignados a esa salida, el tamaño de scriptpubkey y el scriptpubkey actual, que es el script de bloqueo para esa salida. Por último, el campo Nlocktime aplica un valor de tiempo de tiempo en la marca de tiempo o altura del bloque que se aplica a toda la transacción.
Cada transacción de Segwit también contiene una sección de testigos, donde cada entrada tiene un testigo correspondiente que contiene un recuento de elementos de pila, cuántas cosas se colocarán en la pila de script, un campo de tamaño para cada elemento y el elemento de datos actual para ir a la pila.
Cómo funciona CTV
CTV es un código de operación que permite la forma más básica de introspección y datos hacia adelante que realizan todas las propuestas del pacto. Permite que un script tome un hash de 32 bytes predefinido y examine eso con un hash de la mayoría de los campos de la transacción de gasto. Si el hash derivado de la transacción de gasto actual no coincide con el hash predefinido, la transacción no es válida.
Los campos a los que se compromete son:
- castaño
- nlocktime
- Recuento de insumos
- Un hash de todos los campos de Nequence
- Recuento de salida
- Un hash de todas las salidas
- Índice de entrada (el lugar que tiene la entrada en la transacción, primera entrada, 2nd, and so on.)
Estos son todos los campos comprometidos por el hash CTV, en su totalidad y sin capacidad para elegir y elegir. Este es el grado de introspección que CTV permite: “¿El hash de estos campos en la transacción de gastos coincide con el hash en el script de bloqueo de la entrada que se gasta”, eso es todo. El hash se compromete a esencialmente toda la transacción, excepto las entradas reales. Hay una razón por la que el hash no incluye las entradas. Para bloquear una salida a un hash de 32 bytes con CTV, debe conocer el hash de la transacción que está asegurando que es la única forma de gastarse. La entrada bloqueada con CTV que se gasta tendrá que incluir este hash para ser verificado contra CTV. Que requiere tener el hash de esa transacción antes creas la transacción completa. Eso no es posible.
También puede anidar los scripts CTV, es decir, tener una comisión inicial de script CTV con una transacción con salidas que también incluyen scripts CTV. Esto es lo que permite a CTV “llevar adelante”. Sin embargo, todo lo que lleva adelante en la práctica es cualquier datos contenidos en la cadena de transacciones. Puede hacer esto en teoría con una profundidad infinita, pero está limitado en la práctica a una profundidad finita porque la anidación debe generarse hacia atrás desde el last. Esto se debe a que cada nivel, o “salto”, debe hacer que el hash de la transacción se mueva al siguiente; de lo contrario, no puede crear el script de bloqueo en primer lugar. Si aún no conoce la próxima transacción, no puede generar la anterior.
¿Para qué es útil CTV?
CTV le permite restringir una salida para que solo se pueda gastar, de acuerdo con las reglas de consenso, mediante una transacción exacta predefinida. Algunos de ustedes podrían preguntar cuál es el gran problema, ya podemos firmar transacciones. Si el nivel de introspección es tan limitado que solo puede lograr algo que ya podemos hacer solo firmar, ¿cuál es el valor agregado?
Primero, las transacciones previas firmadas siempre dejan abiertas la posibilidad de que los titulares de clave firmen nuevas transacciones y gasten esas monedas de una manera diferente. Debe confiar en que el titular de la llave no hará esto, o eliminará la clave necesaria para firmar (que también tiene que confiar en ellos). CTV elimina esa confianza por completo. Una vez que se outline la transacción de gasto y la salida bloqueada a ese hash CTV se crea, no hay posibilidad de ser gastado de otra manera, aplicado por el consenso.
Actualmente, la única forma de evitar esa confianza es participar en las transacciones previas a la firma usted mismo utilizando MultiSIG. Entonces puede estar completamente seguro de que, a menos que elija firmar uno usted mismo, no se puede crear otra transacción válida que gaste una moneda de manera diferente. El problema es que cuanto más se involucran las personas, más difícil y poco confiable coordinar a todos para firmar una transacción al mismo tiempo. Pasados tamaños pequeños se convierte en un problema totalmente poco práctico resolver de manera confiable.
CTV ofrece una forma de que las personas sepan que un conjunto de transacciones se compromete sin que todos tengan que conectarse al mismo tiempo para firmarlas. Simplifica enormemente el proceso de coordinación al permitir que todos obtengan la información necesaria a cualquier otra persona siempre que puedan, y una vez que esa persona tiene la información de todos, puede crear la cadena de transacciones CTV sin la participación de nadie, y todos pueden verificar y estar seguros de que el resultado correcto es el único posible.
Eso es increíblemente valioso por sí solo, pero CTV también puede permitir cosas aún más valiosas en combinación con otros códigos de operación, que veremos en el próximo artículo.
Pensamientos de cierre
El CTV es un pacto muy restringido que permite un grado de introspección y datos de avance que es tan limitado que no excede la funcionalidad actual de nada que se pueda hacer con transacciones previas firmadas. La propuesta de valor no está en habilitar una nueva funcionalidad por derecho propio, sino mejorar drásticamente la eficiencia, la escalabilidad y las garantías de seguridad de lo que se puede construir actualmente utilizando transacciones previas al firma. Esto solo es un beneficio masivo para casi todos los protocolo implementado actualmente utilizando transacciones previas a la firma.
Estos son algunos de los proyectos que demuestran cuán completamente desarrollados y explorados se compara este pacto explicit con los demás:
- Un grupo de pago básico ejemplo por stutxo.
- Una bóveda de CTV implementación por James O’Beirnequien pasó a proponer OP_Vault (que todavía hace uso de CTV).
- En su lugar, un puerto de prueba de concepto de la implementación de ARK basada en transacciones previamente firmada desde el segundo por Steven Roose para usar CTV.
- El Lenguaje sapio por Jeremy Rubin Él mismo, un lenguaje de nivel superior para construir contratos con CTV (también respalda el uso de transacciones previas al firmado).
- Tiempo de esperauna propuesta para un diseño de coinpool muy básico de John Legislation.
- Numerosos otros Posibles protocoloscomo contratos de registro discretos optimizados (DLC), canales de rayos no interactivos que una parte podría abrir sin la otra, e incluso formas descentralizadas para que los mineros se unan.
CTV es una propuesta increíblemente madura en este punto, con un alto valor agregado y sin riesgo de permitir que nada impulse las preocupaciones en torno a los convenios. Esto no solo debería considerarse muy seriamente, sino que en mi opinión private debería haberse activado hace años.
