-
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
8 changed files
with
165 additions
and
34 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
20 changes: 20 additions & 0 deletions
20
...cec41a56_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.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,20 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode</title> | ||
| <updated>2024-12-13T02:43:09.174831+00:00</updated> | ||
| <author> | ||
| <name>Weikeng Chen 2024-12-12 03:17: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>Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode</title> | ||
| <updated>2024-12-13T02:43:09.174865+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/Z1p5fA6-ZcMtPLOq@console/T/#m38456df1a8a1285cb993f027c7ab7a3bcec41a56" rel="alternate"/> | ||
| <summary>The email conversation focuses on a proposal concerning the naming convention of a Bitcoin opcode, specifically suggesting a change to what is currently termed as OP_SUCCESS. The proposed new name, OP_RETURN_TRUE, is recommended to reduce confusion and align more intuitively with a potential future renaming of OP_RETURN to OP_RETURN_FALSE. This discussion hints at the idea that such a change, while not urgent due to its lack of direct impact on Bitcoin script's capabilities (since the functionality can be emulated), could significantly aid in preventing code bugs and enhancing clarity within the script. | ||
|
|
||
| Additionally, the proposal suggests that this renaming could be considered for inclusion in a significant soft fork, particularly one that introduces tapscript, making it a minor yet potentially valuable addition to a larger update. However, it is also acknowledged that without a pressing need for this renaming due to the absence of immediate functional benefits, the suggestion could remain merely a proposal unless it finds an opportune moment for implementation. This reflects a strategic approach to Bitcoin development, where changes are weighed for their utility and impact before being integrated, even at the level of naming conventions.</summary> | ||
| <published>2024-12-12T03:17:00+00:00</published> | ||
| </entry> | ||
| </feed> |
24 changes: 24 additions & 0 deletions
24
...2a9d191f_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.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>Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode</title> | ||
| <updated>2024-12-13T02:43:00.985831+00:00</updated> | ||
| <author> | ||
| <name>Brandon Black 2024-12-12 05:49: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>Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode</title> | ||
| <updated>2024-12-13T02:43:00.985863+00:00</updated> | ||
| <link href="https://gnusha.org/pi/bitcoindev/Z1p5fA6-ZcMtPLOq@console/T/#mfb23f4c0405bebff0a20a2e771f887002a9d191f" rel="alternate"/> | ||
| <summary>In a recent discussion, the handling of `CODESEPARATOR` segments within the context of Bitcoin's scripting language was analyzed, highlighting a predictable yet distinct approach to managing SUCCESS operations with conditionals. The method entails updating the success mode upon encountering a `CODESEPARATOR`, succeeding if execution is enabled by flow control and the success mode is active, and executing an operation if it is either enabled or a flow control operation itself. | ||
|
|
||
| Further examination of [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) revealed that tapscript designers envisioned a broader utility for the SUCCESS opcode, such as influencing the behavior of other opcodes or even modifying stack limits. However, integrating such functionalities with segmented SUCCESS could present challenges, suggesting that not all envisioned features might be compatible with segmented execution. | ||
|
|
||
| This discourse has led to support for the concept of a runtime success operator, potentially mirroring the functionality of the original RETURN opcode. This alternative could serve useful in scenarios where VERIFY is traditionally utilized, raising questions about the untapped potential of tapscript's `CODESEPARATOR`. | ||
|
|
||
| Additionally, the conversation touched upon the feasibility of implementing restored scripts in tapscript 0xc0, considering the introduction of new opcodes that could redefine existing ones, alter numerical representations, and adjust operational limits. The proposition includes offering a RESTORE opcode that solely activates a mode change, catering to scripts devoid of the new opcodes. This nuanced debate underscores the complexity and evolving nature of Bitcoin script enhancements, reflecting ongoing efforts to refine and expand its capabilities.</summary> | ||
| <published>2024-12-12T05:49:00+00:00</published> | ||
| </entry> | ||
| </feed> |
28 changes: 28 additions & 0 deletions
28
static/delvingbitcoin/Dec_2024/3762_CTV-APO-CAT-activity-on-signet.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,28 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>CTV, APO, CAT activity on signet</title> | ||
| <updated>2024-12-13T02:37:34.391652+00:00</updated> | ||
| <author> | ||
| <name>ajtowns 2024-12-12 05:57:47.375000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>CTV, APO, CAT activity on signet</title> | ||
| <updated>2024-12-13T02:37:34.391721+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/ctv-apo-cat-activity-on-signet/1257/15" rel="alternate"/> | ||
| <summary>The discussion begins by addressing an initial approach to handling precomputed transactions in mining, suggesting a more efficient strategy for computing and caching hashes to avoid the necessity of recalculating vast numbers of hashes. This method proposes caching every 4000th hash and its subsequent hashes up to a certain point, significantly reducing the data required for storage or precalculation, even in scenarios considering long-term operations such as a 1000-year timeframe. | ||
|
|
||
| The conversation then shifts to the challenges faced in garnering attention and participation for demo miners and spacechain nodes. Despite efforts over several months, only a modest number of individuals engaged with the technology. The lack of widespread interest is attributed to the absence of a targeted marketing strategy, which is deemed crucial for attracting attention in the highly dynamic NFT and memecoin spaces. The writer also reflects on missed opportunities for exposure within technical communities and discusses how timing and thematic focus might have impacted visibility. | ||
|
|
||
| Further, the email explores potential innovations for spacechains, including the integration of new programming features and the creation of a currency pegged against established cryptocurrencies. These suggestions aim to enhance functionality and relevance but acknowledge the complexities involved in their implementation. The concept of using utreexo commitments for NFTs is introduced as a means to provide verifiable ownership proofs, albeit with practical limitations noted for their dynamic nature. Additionally, the idea of reverse commitments is mentioned as a possible solution for linking tokens to external data, which could circumvent some of the challenges associated with traditional models. | ||
|
|
||
| The reliability of spacechains in adversarial environments raises questions about validation processes and the risks associated with accepting invalid blocks. The discussion touches on the implications of reorganizations within the blockchain and the potential for double-spending attacks, highlighting the need for further exploration through real implementations. | ||
|
|
||
| The sender recounts personal experiences with running demo miners and spacechain nodes, drawing parallels between their own efforts and early Bitcoin activity to emphasize the importance of patience and persistence in emerging technologies. They also mention the use of a "Nothing Up My Sleeve" approach for a specific covenant to ensure cryptographic integrity. | ||
|
|
||
| Lastly, the email concludes with reflections on previous attempts to document blockchain data and suggestions for future projects. It advocates for strategies that allow for long-term, low-maintenance operation, including automatic content generation and documentation, to facilitate ongoing engagement and accessibility without intensive oversight.</summary> | ||
| <published>2024-12-12T05:57:47.375000+00:00</published> | ||
| </entry> | ||
| </feed> |
20 changes: 20 additions & 0 deletions
20
...63_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.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,20 @@ | ||
| <?xml version='1.0' encoding='UTF-8'?> | ||
| <feed xmlns="http://www.w3.org/2005/Atom"> | ||
| <id>1</id> | ||
| <title>Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions</title> | ||
| <updated>2024-12-13T02:38:22.991404+00:00</updated> | ||
| <author> | ||
| <name>ariard 2024-12-12 06:42:46.666000+00:00</name> | ||
| </author> | ||
| <generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator> | ||
| <entry> | ||
| <id>1</id> | ||
| <title>Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions</title> | ||
| <updated>2024-12-13T02:38:22.991436+00:00</updated> | ||
| <link href="https://delvingbitcoin.org/t/disclosure-irrevocable-fees-stealing-from-ln-using-revoked-commitment-transactions/1314/2" rel="alternate"/> | ||
| <summary>The discussion revolves around the introduction and implications of an upper limit on accepted feerate in the Lightning Development Kit (LDK), highlighting specific versions where these limits were applicable. The initial implementation was aimed at mitigating vulnerabilities related to "irrevocable fees" by introducing a cap on the feerate from a channel counterparty. This strategy was part of broader efforts in 2021 to address issues arising from excessive trimmed HTLCs and dust HTLC exposure, facilitating easier calculation of the msat denominated worst-case scenarios for dust HTLCs exposure through various considered scenarios. Notably, this feature was embedded into the system following a [commit](https://github.com/lightningdevkit/rust-lightning/commit/d3af49e9f07fc28d104f1f1dbcf8e216b65e9f89), marking a significant development in LDK's approach to enhancing security and operational efficiency. | ||
|
|
||
| Furthermore, the conversation extends to the Validating Lightning Signer (VLS) and its role in reinforcing security against fee-related vulnerabilities. Since its pre-production release and notably as of a certain commit, VLS incorporated a `validate_fee()` function, which scrutinizes the counterparty’s proposed feerate against a predefined maximum feerate per kiloweight unit (`max_feerate_per_kw`). This mechanism was specifically designed to thwart "miner-fee-siphoning attacks," a type of vulnerability discussed within the context of VLS since early 2023. The set value for `max_feerate_per_kw` typically stands at 100 satoshi per virtual byte, albeit with provisions for adjustment by operators to suit their operational requirements. This aspect underscores the proactive measures taken by developers to safeguard transactions against evolving threats by implementing configurable limits that adapt to the network's dynamics.</summary> | ||
| <published>2024-12-12T06:42:46.666000+00:00</published> | ||
| </entry> | ||
| </feed> |
Oops, something went wrong.