-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
160 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
18 changes: 18 additions & 0 deletions
18
...-dev/Nov_2024/m90839d5171f2fcee3d399ec21123518c4ebe8836_CHECKSIGFROMSTACK-VERIFY-ADD-.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>CHECKSIGFROMSTACK(VERIFY/ADD)</title> | ||
| <updated>2024-11-24T02:37:19.066405+00:00</updated> | ||
| <author> | ||
| <name>moonsettler 2024-11-23 19:45:00+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>CHECKSIGFROMSTACK(VERIFY/ADD)</title> | ||
| <updated>2024-11-24T02:37:19.066443+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/_p-Du0dVGx1_UqtSLb7UpQRrHWP0JVQOGFeZ3-W-m8eZNNshMsW_oFXw07nAZEnP-YZO6sBn9iF-RY7qK15jxCjQPBMc4LZ-4cesUuRose8=@protonmail.com/T/#m90839d5171f2fcee3d399ec21123518c4ebe8836" rel="alternate"/> | ||
| <summary>The discussion revolves around the potential removal of OP_CHECKSIGFROMSTACKVERIFY (CSFSV), designated as NOP5, from both LNhance and the CSFS BIP. The primary reasons for considering this action include the observation that CSFS is more likely to find its application in Symmetry rather than needing CSFSV specifically. Moreover, it's pointed out that if CSFSV functionality is desired, combining OP_CSFS with OP_VERIFY serves as a viable solution, thereby simplifying the codebase. Additionally, there is a lack of concrete use cases for CSFSV within the legacy system as of now, which strengthens the argument for its removal. The scarcity of upgradeable NOPs further supports the case for eliminating CSFSV to free up space for potentially more useful operations. Furthermore, backporting tapscript is mentioned as a means to bring all necessary functionality to the legacy system, suggesting that removing CSFSV would not result in a loss of capabilities. This proposal reflects a strategic consideration aimed at streamlining and optimizing the development process by focusing on functionalities that offer clear benefits and applications.</summary> | ||
| <published>2024-11-23T19:45:00+00:00</published> | ||
| </entry> | ||
| </feed> |
24 changes: 24 additions & 0 deletions
24
static/delvingbitcoin/Nov_2024/3575_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>OP_PAIRCOMMIT as a candidate for addition to LNhance</title> | ||
| <updated>2024-11-24T02:35:21.247930+00:00</updated> | ||
| <author> | ||
| <name>moonsettler 2024-11-23 15:47:36.827000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>OP_PAIRCOMMIT as a candidate for addition to LNhance</title> | ||
| <updated>2024-11-24T02:35:21.247969+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/13" rel="alternate"/> | ||
| <summary>LNhance fundamentally combines `CTV` and `CSFS`, aiming to facilitate more scalable and less interactive timeout tree and covenant pool constructions. Additionally, it seeks to enable LN-Symmetry, previously known as eltoo, by incorporating `IKEY` for accessing an internal public key from the control block. This key, typically a 2-of-2 MuSig key in lightning channels, allows for cooperative closes on the taproot keypath, thus enhancing contract efficiency. However, an implementation attempt by @instagibbs highlighted a significant drawback – the "data availability problem" of LN-Symmetry, where a channel peer cannot reconstruct the script for spending an intermediate state pushed on chain due to the non-deterministic nature of fund distribution for that particular state. To address this issue, utilizing the taproot annex was proposed as an alternative solution. | ||
|
|
||
| The discussion around potential solutions included several alternatives. `OP_CAT` was considered for its ability to combine multiple stack elements for verification via `OP_CHECKSIGFROMSTACK` as a valid state update. Despite its potential, `OP_CAT` introduces challenges, such as enabling bigint operations and extending the arithmetic capabilities of Bitcoin script, which could be controversial. Streaming SHA256 opcodes were seen as a viable alternative, offering similar functionalities for introspection but potentially allowing custom construction of sighashes like CTV templates. Merkle operation opcodes, on the other hand, were deemed of limited use and difficult to justify without `OP_CAT` due to their complexity and resource cost. The notion of a 'Kitty' CAT was briefly entertained but ultimately dismissed due to its awkward limitations and weak introspection capabilities. | ||
|
|
||
| Moreover, `OP_CHECKTEMPLATEVERIFY` was discussed for committing to the taproot annex in tapscript, which, despite its potential for making various protocols more efficient, faced controversy and lacked consensus on usage and structure. `OP_CHECKSIGFROMSTACK` was revisited for its application on n elements as a message, highlighting its complexity and arbitrary nature. `OP_VECTORCOMMIT` emerged as a generalized solution for committing to more than two stack elements, yet its practicality was questioned due to concerns about setting proper limits and operational complexity. | ||
|
|
||
| Looking forward, the integration of LNhance with `OP_CHECKCONTRACTVERIFY` (or `CCV`, central to MATT by @salvatoshi) or `OP_VAULT/RECOVER` (BIP-345 by @jamesob) is seen as promising for facilitating robust vaults featuring flexible withdrawal amounts and immediate re-vaulting of change. Both improvements presuppose the availability of `OP_CHECKTEMPLATEVERIFY` and particularly benefit from `OP_PAIRCOMMIT` for handling multiple stack elements efficiently.</summary> | ||
| <published>2024-11-23T15:47:36.827000+00:00</published> | ||
| </entry> | ||
| </feed> |
81 changes: 81 additions & 0 deletions
81
...delvingbitcoin/Nov_2024/combined_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>2</id> | ||
| <title>Combined summary - OP_PAIRCOMMIT as a candidate for addition to LNhance</title> | ||
| <updated>2024-11-24T02:35:40.550276+00:00</updated> | ||
| <author> | ||
| <name>moonsettler 2024-11-23 15:47:36.827000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-29 11:36:58.752000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>ajtowns . 2024-10-29 10:52:30.693000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-29 09:38:38.311000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-28 12:05:19.886000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>ajtowns . 2024-10-28 11:16:51.953000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-25 21:50:45.243000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>bytes . 2024-10-25 19:22:36.211000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-25 19:11:15.643000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-25 19:06:11.290000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>bytes . 2024-10-25 17:57:14.444000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-25 14:38:37.937000+00:00</name> | ||
| </author> | ||
| <author> | ||
| <name>moonsettler . 2024-10-25 14:34:33.286000+00:00</name> | ||
| </author> | ||
| <link href="delvingbitcoin/Nov_2024/3575_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3437_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3436_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3435_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3431_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3430_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3409_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3407_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3406_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3405_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3404_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3402_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <link href="delvingbitcoin/Oct_2024/3401_OP-PAIRCOMMIT-as-a-candidate-for-addition-to-LNhance.xml" rel="alternate"/> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>2</id> | ||
| <title>Combined summary - OP_PAIRCOMMIT as a candidate for addition to LNhance</title> | ||
| <updated>2024-11-24T02:35:40.550368+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/13" rel="alternate"/> | ||
| <summary>LNhance aims to enhance the scalability and efficiency of timeout tree and covenant pool constructions while enabling LN-Symmetry, previously known as eltoo. The introduction of `IKEY` facilitates access to the internal public key from the control block, primarily in a lightning channel scenario, allowing for cooperative closes on the taproot keypath. This innovation significantly streamlines contract efficiency. A challenge identified is the "data availability problem" associated with LN-Symmetry, where the inability of a channel peer to reconstruct the script of an intermediate state pushed on-chain jeopardizes one of Symmetry's main advantages: the obviation of backup maintenance. Despite deterministic aspects, the specific fund distribution for any given state remains unpredictable. | ||
|
|
||
| Discussions around alternatives to address this issue include the potential use of the taproot annex and various opcode proposals such as `OP_CAT`, SHA256 streaming opcodes, Merkle operation opcodes, and more restrictive versions of `OP_CAT`. Each alternative comes with its own set of complexities and implications for Bitcoin script capabilities. Notably, `OP_PAIRCOMMIT` emerges as a solution specifically designed to avoid introducing controversial behaviors while addressing the data availability problem by facilitating the combination of multiple stack elements into a single, verifiable state update. | ||
|
|
||
| The development of OP_PAIRCOMMIT is detailed, with progress shared publicly on GitHub. This effort reflects a broader initiative to improve BINANA's functionality through the integration of new features like OP_PAIRCOMMIT. The management of digital communication within programming projects is also highlighted, advocating for strategic thread handling and incremental updates to foster ongoing dialogue among contributors. | ||
|
|
||
| Further discussion touches on Bitcoin Improvement Proposals (BIPs), including a suggestion to streamline the CheckTemplateVerify (CTV) process by eliminating the `DUP VERIFY` step when the hash argument is 0 bytes. This proposal underscores a collective effort to refine and optimize Bitcoin scripting practices. | ||
|
|
||
| In parallel, the conversation delves into technical challenges and solutions related to LN-Symmetry, particularly focusing on optimizing SHA256 iterations. A methodical approach to constructing hashes is proposed to minimize computational demands while ensuring security against length redistribution attacks—an important consideration given CTV's fixed 32-byte template requirement. | ||
|
|
||
| Amid these technical discussions, a request for feedback on hashing methodologies signifies a keen interest in evaluating the security and efficiency of current practices. This inquiry exemplifies the ongoing quest for improvements within the Bitcoin development community. | ||
|
|
||
| Moreover, debates surrounding the adoption of new opcodes like OP_CAT versus maintaining system simplicity reflect broader developmental strategies. The prioritization of foundational opcodes such as OP_CTV before exploring more complex innovations suggests a measured approach to integrating new functionalities. | ||
|
|
||
| Finally, the utilization of Vector Commitments, exemplified by `OP_PAIRCOMMIT`, demonstrates a concerted effort to enhance security and simplify contract scripting on the blockchain. This approach, combined with detailed specifications for managing contract states, represents significant advancements in securing and streamlining blockchain contracts, aligning with the overarching goal of fostering a secure, efficient, and user-friendly blockchain ecosystem.</summary> | ||
| <published>2024-11-23T15:47:36.827000+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.