Es la segunda parte de una serie. serie Un análisis detallado de convenios individuales que son lo suficientemente maduros como para garantizar un desglose exhaustivo.
ChecksigFromstack Brandon Black y la propuesta de Jeremy Rubin (CSFS) para BIP348 con Brandon Black no es un contrato. Como mencioné en mi artículo introductorio, cubriré algunas propuestas que no son convenios. Sin embargo, se sinergan y/o se interrelacionan de cierta manera con esos convenios. CSFS, por ejemplo, es un buen primer paso.
CSFS puede ser un código de operación relativamente simple. Sin embargo, antes de analizar cómo funciona, primero echemos un vistazo más de cerca a cómo funciona realmente un script de bitcoin.
Es un lenguaje basado en pila. Esto significa que los datos se almacenan en pilas. “Apilado”, la pila está apilada una encima de la otra, y los códigos de operación se aplican mediante los datos que devuelven la parte superior o el resultado de una operación.
Cuando se ejecuta y verifica un script, tiene dos partes distintas. “Testigo” El testigo/guión de desbloqueo se incluye con la salida. Este testigo/guión de desbloqueo está “agregado”, la pila está construida desde el lado derecho a la izquierda del script de bloqueo. Eche un vistazo al ejemplo a continuación. “|“El testigo debe marcar los límites entre el guión y los testigos.
1 2 | On_add 3 on_equal
El código de ejemplo agrega valor al script “1” El valor se agrega a la pila. “2” además de esto. OP_Add agrega los dos elementos superiores y pone el resultado en la pila. “3”). “” 3 “Esto se agrega a la pila. El elemento final, Op_equal toma los dos elementos más altos en la pila, y devuelve un número” 1 “y Verdadero/Falso están representados en la pila 1 y 0.
Si la transacción no es válida, se considerará que el consenso ha fallado.
Aquí hay un ejemplo del script básico de Pay-To PubKey-Hash (P2PKH). Las direcciones heredadas comienzan con la letra A “1”:
La clave pública y la firma se agregan por primera vez a la pila. A continuación se llama DUP, que duplica y luego devuelve el elemento en la parte superior a la pila. Hash160 devuelve el hash de la duplicación de la clave pública al elemento superior en la pila. El hash de la clave pública del guión se coloca en la parte superior de la pila. Funciona de la misma manera que igual. Se agarran los dos elementos en la parte superior de la pila y se devuelve el resultado 1 o 0, dependiendo de si el elemento fue 1. Equalverify ejecuta Verify, que elimina y falla la transacción si el elemento superior de la pila no es 1. Checksig, el paso final, toma tanto el pubkey como la firma de la pila, suponiendo que es una firma. Luego verifica la firma contra el valor hash de la transacción. Colocará un 1 en la parte superior de la pila si es válida.
¿Qué es CSFS?
Checksig ha sido uno de los códigos de operación más populares para Bitcoin. Cada transacción usa este código de operación en su script, casi sin excepción. El protocolo de Bitcoin se basa en la verificación de la firma. Hay muy poca flexibilidad cuando se trata de lo que verifica la firma. CheckSig solo verifica una firma en relación con la transacción que se está verificando. Puede elegir ser flexible, por ejemplo. Hay cierta flexibilidad, es decir
CSFS tiene como objetivo cambiar esto, permitiendo que un mensaje se empuje a la pila directamente y posteriormente verificado. Esta es una mejora sobre el sistema actual que solo permite que las firmas se verifiquen con transacciones. La estructura operativa del código de operación es muy simple:
El mensaje se coloca en la parte superior, seguido de la clave pública. CSFS tomará los tres elementos más altos en la pila y verificará la firma con el mensaje. Se colocará un 1 si la firma ha sido validada.
Eso es todo. La variante CheckSIG que permite al usuario ingresar mensajes arbitrarios además de solo gastar transacciones.
¿Para qué es útil los CSF?
¿Qué hace esto exactamente? ¿Por qué verificar una firma en una pila de mensajes aleatorios en lugar de la transacción de gasto real?
Primero, combina con CTV Se puede utilizar para proporcionar funcionalidad que los desarrolladores de Lightning querían desde el principio: firmas flotantes que se pueden conectar a varias transacciones. Inicialmente se propuso como un campo de sighash para firmas. (El campo que dicta a qué parte de una transacción se aplica una firma). Era necesario porque la firma de una transacción cubre la ID de la transacción original. Una firma solo se puede usar para transacciones que gastan la salida. Se desconoce la redacción exacta. producción.
Es el comportamiento deseado para los rayos, ya que nos permite eliminar las sanciones del canal. Cada transacción y clave pasadas debe coincidir con el estado anterior para asegurarse de que su contraparte no intente usar ninguno para intentar reclamar dinero que no poseen. No pueden reclamar sus fondos a menos que intenten hacerlo. Simplemente puede usar algo superior si le permite hacerlo. “Adjuntar” la transacción actual debe compararse con las transacciones anteriores para evitar el robo distribuyendo correctamente los fondos en lugar de confiscar el dinero.
Un script básico puede lograr esto tomando una firma CTV y colocándola sobre un CTV-Hash. Esto luego se verifica con CSFS. Sería posible tener cualquier salida creada por este script gasten cualquier firma de transacción firmada por la clave CSFS.
La delegación de control sobre un UTXO es otra característica útil. El script puede verificar si un hash CTV, firmado por un CSFS, es válido para gastar un UTXO. Se pueden agregar otras variables, como una clave pública recién creada, al guión. El script se puede construir para permitir que una tecla CSFS se firme. Los siguientes son algunos ejemplos de cómo usar Clave pública que se puede utilizar para validar un checksig usando CSFS. Luego podría delegar a otra persona el poder de gastar un UTXO sin moverlo a la cadena.
CSFS, cuando se combina con CAT, puede crear una funcionalidad de introspección mucho más sofisticada. Sin embargo, veremos en la siguiente parte de esta serie que los CSF no necesitan usarse para imitar un comportamiento más complejo. El gato puede hacerlo.
Pensamientos cerrados
CSFS, un código de operación básico que ofrece una funcionalidad simple por sí sola, pero también compone bien con los códigos de operación de pacto más simples para proporcionar una funcionalidad muy útil. El ejemplo de las firmas flotantes anteriores es específico de la red Lightning. Sin embargo, las firmas flotantes se pueden usar en cualquier protocolo que use transacciones de bitcoins prefirmadas.
La delegación de script va más allá del control de los delegados a un UTXO. Esta misma habilidad también está disponible para las variables “Sideload” se pueden agregar a un script después de que se haya ejecutado. Esto no se limita a las claves públicas. Los valores de Timelock, el hashlock preimages, etc. Ahora, cualquier script que codifica una variable de entrada para la verificación puede tener los valores agregados dinámicamente después.
También es una propuesta madura. La implementación se ha ejecutado en Liquid Network (se basa en el líquido CodeBase) y los elementos. Desde 2016. Bitcoin Cash, por otro lado, tiene un versión Desde 2018, ha sido parte de la.
CSFS, una propuesta con una larga historia, es un concepto bien desarrollado. He estado trabajando en esta área durante casi la misma cantidad de tiempo. Existen múltiples implementaciones maduras, así como casos de uso muy específicos a los que puede aplicarse.
“ItAilyCrypto no es responsable de las actividades que realice fuera de su DailyCrypto”.
