• About Us
  • Privacy Policy
  • Disclaimer
  • Contact Us
Coin Snap
  • Home
  • Bitcoin
  • Defi
  • Crypto Mining
  • Crypto News
No Result
View All Result
  • Home
  • Bitcoin
  • Defi
  • Crypto Mining
  • Crypto News
No Result
View All Result
Coin Snap
No Result
View All Result
Home Bitcoin

Pactos de Bitcoin: CheckSigFromstack (BIP 348)

luiselduque22 by luiselduque22
April 6, 2025
in Bitcoin
0
Pactos de Bitcoin: CheckSigFromstack (BIP 348)
189
SHARES
1.5k
VIEWS
Share on FacebookShare on Twitter


Este es el segundo 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.

ChecksigFromstack (CSF), presentado por Brandon Black y Jeremy Rubin con BIP 348, no es un pacto. Como dije en el artículo introductorio de esta serie, algunas de las propuestas que estaría cubriendo no son convenios, sino que sinergen o se interrelacionan con ellas de alguna manera. CSFS es el primer ejemplo de eso.

CSFS es un código de operación muy easy, pero antes de pasar por cómo funciona, veamos los conceptos básicos de cómo funciona realmente un script de bitcoin.

El script es un lenguaje basado en pila. Eso significa que los datos están “apilados” juntos uno encima del otro en la pila, y se operan eliminando un elemento de la parte superior de la pila para operar en función de lo que hace un código de operación, ya sea devolviendo los datos o un resultado de él a la parte superior de la pila.

Hay dos partes de un script cuando finalmente se ejecuta y verifica, el “testigo” proporcionado para desbloquear el script, y el script incluido en la salida que se gasta. El script de testigo/desbloqueo se “agrega” al lado izquierdo del script de bloqueo, y luego cada elemento se agrega (u opera) la pila una por una de izquierda a derecha. Mira este ejemplo (el “|“Marca el límite entre el testigo y el guión):

1 2 | OP_ADD 3 OP_ECHAL

Este script de ejemplo agrega el valor “1” a la pila, luego el valor “2” además de eso. OP_Add toma los dos elementos principales de la pila y los agrega, poniendo el resultado de nuevo en la pila (así que ahora todo lo que está en la pila es “3”). Luego se agrega otro “3” a la pila. El último elemento, Op_Equal, toma los dos elementos principales de la pila y devuelve un “1” a la pila (1 y 0 pueden representar los números verdaderos o falsos y falsos).

Un script debe terminar con el último elemento en la parte superior de la pila que es verdadera, de lo contrario, el script (y la transacción que lo ejecuta) falla y se considera un consenso inválido.

Este es un ejemplo básico de un script de pago a Pubkey-Hash (P2PKH), es decir, las direcciones heredadas que comienzan con un “1”:

| Dup hash160 CHECKSIG DE CHECKECTIVO DE MALIA

Primero, la firma y la clave pública se agregan a la pila. Luego se llama a DUP, que toma el elemento de la pila superior y lo duplica, devolviéndolo a la parte superior de la pila. Hash160 toma el elemento de la pila superior (el duplicado de la clave pública), lo hashes, luego lo devuelve a la parte superior de la pila. El hash de la clave pública del guión se coloca en la parte superior de la pila. Equalverify funciona igual que igual, toma los dos elementos de pila superior y devuelve un 1 o 0 en función del resultado. La única diferencia es que igualverify también se ejecuta verificar después de igual, lo que falla la transacción si el elemento de pila superior no es 1, y también elimina el elemento de la pila superior. Finalmente, se ejecuta Checksig, que toma los dos elementos de la pila superiores suponiendo que sean una firma y un pubkey, y verifica la firma implícitamente contra el hash de la transacción que se verifica. Si es válido, coloca un 1 encima de la pila.

Cómo funciona CSFS

CheckSig es uno de los códigos de operación más utilizados en Bitcoin. Cada transacción, casi sin excepciones, hace uso de este código de operación en algún momento de uno de sus scripts. La verificación de la firma es un componente basic del protocolo de bitcoin. El problema es que casi no hay flexibilidad en términos de qué mensaje está verificando la firma. CheckSig solo verificará una firma contra la transacción que se está verificando. Hay cierta flexibilidad, es decir, puede decidir con cierto grado de libertad a qué partes de la transacción se aplica la firma, pero eso es todo.

CSFS tiene como objetivo cambiar esto al permitir que se verifique una firma contra cualquier mensaje arbitrario que se empuje directamente a la pila, en lugar de limitarse a la verificación de firmas contra la transacción misma. El código de operación sigue una estructura operativa muy básica:

| CSFS

La firma y el mensaje se dejan caer en la parte superior de la pila, luego la clave pública en la parte superior de ellos, y finalmente CSF toma los tres elementos principales de la pila suponiendo que sean la clave pública, el mensaje y la firma de arriba a abajo, verificando la firma contra el mensaje. Si la firma es válida, se coloca un 1 en la pila.

Eso es todo. Una variante easy de checksig que permite a los usuarios especificar mensajes arbitrarios en lugar de solo la transacción de gasto.

¿Para qué es útil los CSF?

Entonces, ¿para qué es exactamente esto bueno? ¿Cuál es el uso de verificar una firma contra un mensaje arbitrario en la pila en lugar de contra la transacción de gastos?

En primer lugar, en combinación con CTV Puede proporcionar una funcionalidad equivalente a algo que los desarrolladores de Lightning han querido desde el principio, firmas flotantes que pueden unirse a diferentes transacciones. Esto se propuso originalmente como una nueva bandera de Sighash para firmas (el campo que dicta a qué partes de una transacción se aplica una firma). Esto period necesario porque una firma de transacción cubre la ID de transacción de la transacción que creó la salida que se gasta. Esto significa que una firma solo es válida para un gasto de transacción que exacto producción.

Este es un comportamiento deseado para Lightning porque nos permitiría eliminar las penalizaciones del canal. Cada estado de relámpago pasado necesita una clave de penalización y una transacción para garantizar que su contraparte de canal nunca use ninguno de ellos para tratar de reclamar fondos que no poseen. Si lo intentan, puede reclamar todo su dinero. Una funcionalidad superior sería algo que le permite simplemente “adjuntar” la transacción de estado precise a cualquiera anterior para detener el intento de robo distribuyendo fondos correctamente en lugar de confiscarlos.

Esto se puede lograr con un script básico que toma un hash CTV y una firma sobre él que se verifica con CSFS. Esto permitiría cualquier hash de transacción firmado por esa clave CSFS para gastar cualquier salida que se cree con este script.

Otra característica útil es la delegación de management de un UTXO. De la misma manera que cualquier hash CTV firmado por una clave CSFS puede gastar válidamente un UTXO con un script diseñado para eso, otras variables se pueden transmitir al guión para verificar, como una nueva clave pública. Se podría construir un script que permita que una tecla CSFS se inicie cualquier Public Key, que luego podría validarse utilizando CSF ​​y utilizado para una validación de SIG de verificación regular. Esto le permitiría delegar la capacidad de gastar un utxo en cualquier otra persona sin tener que moverlo en la cadena.

Por último, en combinación con CAT, los CSF se pueden usar para componer funcionalidad de introspección mucho más compleja. Sin embargo, como veremos más adelante en la serie, CSFS no se requiere realmente para emular nada de este comportamiento más avanzado, ya que Cat Alone puede hacerlo.

Pensamientos de cierre

CSFS es un código de operación muy básico que, además de ofrecer una funcionalidad útil easy por derecho propio, compone muy bien con los códigos de operación de pacto más simples para crear una funcionalidad muy útil. Si bien el ejemplo anterior con respecto a las firmas flotantes hace referencia específicamente a la purple Lightning, las firmas flotantes son una primitiva generalmente útil que son aplicables a cualquier protocolo basado en Bitcoin que utiliza las transacciones previas al firma.

Además de las firmas flotantes, la delegación de script es una primitiva muy útil que generaliza mucho más allá de delegar el management sobre un UTXO a una nueva clave pública. La misma capacidad básica para “volver a encender” variables después del hecho de un flujo de validación de script puede aplicarse a cualquier cosa, no solo las claves públicas. Los valores de Timelock, el hashlock preimages, and so on. Cualquier script que codifique una variable para verificar ahora puede tener esos valores agregados dinámicamente después del hecho.

Además de eso, CSFS es una propuesta muy madura. Tiene una implementación que ha estado en vivo en la purple y elementos de Liquid (el CodeBase Liquid usa) Desde 2016. Además, Bitcoin Money ha tenido un versión de eso desde 2018.

CSFS es una propuesta muy madura que se remonta conceptualmente casi tanto tiempo como he estado en este espacio, con múltiples implementaciones maduras, y casos de uso muy claros a los que se puede aplicar.

Related articles

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

July 9, 2025
Bitcoin apareció en DC, y Washington se dio cuenta

Bitcoin apareció en DC, y Washington se dio cuenta

July 8, 2025


Este es el segundo 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.

ChecksigFromstack (CSF), presentado por Brandon Black y Jeremy Rubin con BIP 348, no es un pacto. Como dije en el artículo introductorio de esta serie, algunas de las propuestas que estaría cubriendo no son convenios, sino que sinergen o se interrelacionan con ellas de alguna manera. CSFS es el primer ejemplo de eso.

CSFS es un código de operación muy easy, pero antes de pasar por cómo funciona, veamos los conceptos básicos de cómo funciona realmente un script de bitcoin.

El script es un lenguaje basado en pila. Eso significa que los datos están “apilados” juntos uno encima del otro en la pila, y se operan eliminando un elemento de la parte superior de la pila para operar en función de lo que hace un código de operación, ya sea devolviendo los datos o un resultado de él a la parte superior de la pila.

Hay dos partes de un script cuando finalmente se ejecuta y verifica, el “testigo” proporcionado para desbloquear el script, y el script incluido en la salida que se gasta. El script de testigo/desbloqueo se “agrega” al lado izquierdo del script de bloqueo, y luego cada elemento se agrega (u opera) la pila una por una de izquierda a derecha. Mira este ejemplo (el “|“Marca el límite entre el testigo y el guión):

1 2 | OP_ADD 3 OP_ECHAL

Este script de ejemplo agrega el valor “1” a la pila, luego el valor “2” además de eso. OP_Add toma los dos elementos principales de la pila y los agrega, poniendo el resultado de nuevo en la pila (así que ahora todo lo que está en la pila es “3”). Luego se agrega otro “3” a la pila. El último elemento, Op_Equal, toma los dos elementos principales de la pila y devuelve un “1” a la pila (1 y 0 pueden representar los números verdaderos o falsos y falsos).

Un script debe terminar con el último elemento en la parte superior de la pila que es verdadera, de lo contrario, el script (y la transacción que lo ejecuta) falla y se considera un consenso inválido.

Este es un ejemplo básico de un script de pago a Pubkey-Hash (P2PKH), es decir, las direcciones heredadas que comienzan con un “1”:

| Dup hash160 CHECKSIG DE CHECKECTIVO DE MALIA

Primero, la firma y la clave pública se agregan a la pila. Luego se llama a DUP, que toma el elemento de la pila superior y lo duplica, devolviéndolo a la parte superior de la pila. Hash160 toma el elemento de la pila superior (el duplicado de la clave pública), lo hashes, luego lo devuelve a la parte superior de la pila. El hash de la clave pública del guión se coloca en la parte superior de la pila. Equalverify funciona igual que igual, toma los dos elementos de pila superior y devuelve un 1 o 0 en función del resultado. La única diferencia es que igualverify también se ejecuta verificar después de igual, lo que falla la transacción si el elemento de pila superior no es 1, y también elimina el elemento de la pila superior. Finalmente, se ejecuta Checksig, que toma los dos elementos de la pila superiores suponiendo que sean una firma y un pubkey, y verifica la firma implícitamente contra el hash de la transacción que se verifica. Si es válido, coloca un 1 encima de la pila.

Cómo funciona CSFS

CheckSig es uno de los códigos de operación más utilizados en Bitcoin. Cada transacción, casi sin excepciones, hace uso de este código de operación en algún momento de uno de sus scripts. La verificación de la firma es un componente basic del protocolo de bitcoin. El problema es que casi no hay flexibilidad en términos de qué mensaje está verificando la firma. CheckSig solo verificará una firma contra la transacción que se está verificando. Hay cierta flexibilidad, es decir, puede decidir con cierto grado de libertad a qué partes de la transacción se aplica la firma, pero eso es todo.

CSFS tiene como objetivo cambiar esto al permitir que se verifique una firma contra cualquier mensaje arbitrario que se empuje directamente a la pila, en lugar de limitarse a la verificación de firmas contra la transacción misma. El código de operación sigue una estructura operativa muy básica:

| CSFS

La firma y el mensaje se dejan caer en la parte superior de la pila, luego la clave pública en la parte superior de ellos, y finalmente CSF toma los tres elementos principales de la pila suponiendo que sean la clave pública, el mensaje y la firma de arriba a abajo, verificando la firma contra el mensaje. Si la firma es válida, se coloca un 1 en la pila.

Eso es todo. Una variante easy de checksig que permite a los usuarios especificar mensajes arbitrarios en lugar de solo la transacción de gasto.

¿Para qué es útil los CSF?

Entonces, ¿para qué es exactamente esto bueno? ¿Cuál es el uso de verificar una firma contra un mensaje arbitrario en la pila en lugar de contra la transacción de gastos?

En primer lugar, en combinación con CTV Puede proporcionar una funcionalidad equivalente a algo que los desarrolladores de Lightning han querido desde el principio, firmas flotantes que pueden unirse a diferentes transacciones. Esto se propuso originalmente como una nueva bandera de Sighash para firmas (el campo que dicta a qué partes de una transacción se aplica una firma). Esto period necesario porque una firma de transacción cubre la ID de transacción de la transacción que creó la salida que se gasta. Esto significa que una firma solo es válida para un gasto de transacción que exacto producción.

Este es un comportamiento deseado para Lightning porque nos permitiría eliminar las penalizaciones del canal. Cada estado de relámpago pasado necesita una clave de penalización y una transacción para garantizar que su contraparte de canal nunca use ninguno de ellos para tratar de reclamar fondos que no poseen. Si lo intentan, puede reclamar todo su dinero. Una funcionalidad superior sería algo que le permite simplemente “adjuntar” la transacción de estado precise a cualquiera anterior para detener el intento de robo distribuyendo fondos correctamente en lugar de confiscarlos.

Esto se puede lograr con un script básico que toma un hash CTV y una firma sobre él que se verifica con CSFS. Esto permitiría cualquier hash de transacción firmado por esa clave CSFS para gastar cualquier salida que se cree con este script.

Otra característica útil es la delegación de management de un UTXO. De la misma manera que cualquier hash CTV firmado por una clave CSFS puede gastar válidamente un UTXO con un script diseñado para eso, otras variables se pueden transmitir al guión para verificar, como una nueva clave pública. Se podría construir un script que permita que una tecla CSFS se inicie cualquier Public Key, que luego podría validarse utilizando CSF ​​y utilizado para una validación de SIG de verificación regular. Esto le permitiría delegar la capacidad de gastar un utxo en cualquier otra persona sin tener que moverlo en la cadena.

Por último, en combinación con CAT, los CSF se pueden usar para componer funcionalidad de introspección mucho más compleja. Sin embargo, como veremos más adelante en la serie, CSFS no se requiere realmente para emular nada de este comportamiento más avanzado, ya que Cat Alone puede hacerlo.

Pensamientos de cierre

CSFS es un código de operación muy básico que, además de ofrecer una funcionalidad útil easy por derecho propio, compone muy bien con los códigos de operación de pacto más simples para crear una funcionalidad muy útil. Si bien el ejemplo anterior con respecto a las firmas flotantes hace referencia específicamente a la purple Lightning, las firmas flotantes son una primitiva generalmente útil que son aplicables a cualquier protocolo basado en Bitcoin que utiliza las transacciones previas al firma.

Además de las firmas flotantes, la delegación de script es una primitiva muy útil que generaliza mucho más allá de delegar el management sobre un UTXO a una nueva clave pública. La misma capacidad básica para “volver a encender” variables después del hecho de un flujo de validación de script puede aplicarse a cualquier cosa, no solo las claves públicas. Los valores de Timelock, el hashlock preimages, and so on. Cualquier script que codifique una variable para verificar ahora puede tener esos valores agregados dinámicamente después del hecho.

Además de eso, CSFS es una propuesta muy madura. Tiene una implementación que ha estado en vivo en la purple y elementos de Liquid (el CodeBase Liquid usa) Desde 2016. Además, Bitcoin Money ha tenido un versión de eso desde 2018.

CSFS es una propuesta muy madura que se remonta conceptualmente casi tanto tiempo como he estado en este espacio, con múltiples implementaciones maduras, y casos de uso muy claros a los que se puede aplicar.

Tags: bipBitcoinCheckSigFromstackPactos
Share76Tweet47

Related Posts

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

by luiselduque22
July 9, 2025
0

Los datos en la cadena muestran que la Reserva Binance Trade ha divergido entre Bitcoin y Stablecoins. Esto es lo...

Bitcoin apareció en DC, y Washington se dio cuenta

Bitcoin apareció en DC, y Washington se dio cuenta

by luiselduque22
July 8, 2025
0

Por Zack Cohen, Bitcoin Coverage Institute Antes de sumergirme en el resumen, quiero agradecer. En nombre de todo el equipo...

Bybit Card Dobles Temporada de compras Pleasure con 20% de reembolso

Bybit Card Dobles Temporada de compras Pleasure con 20% de reembolso

by luiselduque22
July 8, 2025
0

Dubai, EAU, 8 de julio de 2025 / PRNewswire / - Bybitel segundo cambio de criptomonedas más grande del mundo...

Problema de Webpack con Tiny-SECP256K1 y Ecpair

Problema de Webpack con Tiny-SECP256K1 y Ecpair

by luiselduque22
July 8, 2025
0

Estoy desarrollando una extensión del navegador utilizando Webpack V5 e incorporando las bibliotecas Bitcoinjs-Lib y Ecpair para crear una billetera...

Bitcoin NFTS alcanzó las ventas de todos los tiempos de $ 5.5B, como inscripciones cerca de 100m

Bitcoin NFTS alcanzó las ventas de todos los tiempos de $ 5.5B, como inscripciones cerca de 100m

by luiselduque22
July 7, 2025
0

Unirse a nuestro Telegrama canal para mantenerse al día sobre la cobertura de noticias de última hora A pesar del...

Load More
  • Trending
  • Comments
  • Latest
Ethereum en la cúspide de una gran ruptura en el primer trimestre de 2025, se espera que las altcoins sigan su ejemplo

Ethereum en la cúspide de una gran ruptura en el primer trimestre de 2025, se espera que las altcoins sigan su ejemplo

December 28, 2024
Raoul Pal califica el patrón gráfico de Ethereum como “uno de los más poderosos en criptografía”, lo que indica que se avecina una gran ruptura ⋆ ZyCrypto

Raoul Pal califica el patrón gráfico de Ethereum como “uno de los más poderosos en criptografía”, lo que indica que se avecina una gran ruptura ⋆ ZyCrypto

December 27, 2024
El impulso alcista impulsa el impulso hacia los $6

El impulso alcista impulsa el impulso hacia los $6

January 7, 2025
6 mejores altcoins para invertir hoy 30 de enero – OKB, Mantra, Onyxcoin

6 mejores altcoins para invertir hoy 30 de enero – OKB, Mantra, Onyxcoin

January 30, 2025
¿Ha terminado la temporada de Memecoin? PEPE y SHIB luchan mientras Lunex se eleva

¿Ha terminado la temporada de Memecoin? PEPE y SHIB luchan mientras Lunex se eleva

0
Comprensión de los rendimientos y la economía de las apuestas en Ethereum y Solana

Comprensión de los rendimientos y la economía de las apuestas en Ethereum y Solana

0
Calienta tu hogar mientras ganas Bitcoin con Heatbit

Calienta tu hogar mientras ganas Bitcoin con Heatbit

0
Líderes de IcomTech sentenciados a una década tras las rejas

Líderes de IcomTech sentenciados a una década tras las rejas

0
Los titulares de Hypers cambian los fondos a medida que el nuevo proyecto se prepara para lanzar

Los titulares de Hypers cambian los fondos a medida que el nuevo proyecto se prepara para lanzar

July 9, 2025
Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

July 9, 2025
La encuesta encuentra lagunas en la cobertura de Bitcoin convencional, dejando a los inversores institucionales expuestos

La encuesta encuentra lagunas en la cobertura de Bitcoin convencional, dejando a los inversores institucionales expuestos

July 9, 2025
Bitcoin apareció en DC, y Washington se dio cuenta

Bitcoin apareció en DC, y Washington se dio cuenta

July 8, 2025

Coinsnap-Pro

Welcome to CoinSnap Pro, your ultimate destination for everything related to decentralized finance (DeFi), cryptocurrency news, Bitcoin, and crypto mining. Our mission is to keep you informed and empowered in the ever-evolving world of digital assets and blockchain technology.

Categories

  • Bitcoin
  • Crypto Mining
  • Crypto News
  • Defi
  • Economía

Recent News

Los titulares de Hypers cambian los fondos a medida que el nuevo proyecto se prepara para lanzar

Los titulares de Hypers cambian los fondos a medida que el nuevo proyecto se prepara para lanzar

July 9, 2025
Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

Bitcoin y Stablecoin Reservas Diverge on Binance: ¿Cabezza de explosión de liquidez?

July 9, 2025
  • About Us
  • Privacy Policy
  • Disclaimer
  • Contact Us

© 2024 Coinsnap.pro. All rights reserved.

No Result
View All Result
  • Home
  • Bitcoin
  • Defi
  • Crypto Mining
  • Crypto News

© 2024 Coinsnap.pro. All rights reserved.