diff --git a/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml b/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml index 8b7e5d7df..2daaef255 100644 --- a/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml +++ b/static/bitcoin-dev/Dec_2024/combined_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml @@ -2,7 +2,13 @@ 2 Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode - 2024-12-10T02:47:14.139119+00:00 + 2024-12-13T02:43:22.781715+00:00 + + Brandon Black 2024-12-12 05:49:00+00:00 + + + Weikeng Chen 2024-12-12 03:17:00+00:00 + Brandon Black 2024-12-09 22:06:00+00:00 @@ -12,6 +18,8 @@ Weikeng Chen 2024-12-09 13:27:00+00:00 + + @@ -19,15 +27,13 @@ 2 Combined summary - Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode - 2024-12-10T02:47:14.139175+00:00 + 2024-12-13T02:43:22.781772+00:00 - In the ongoing discourse on Bitcoin script development, an innovative approach has been suggested to enhance script execution efficiency by modifying the behavior of the "OP_SUCCESS" opcode without introducing a new opcode, namely "OP_SEGMENT". This modification leverages the existing "OP_CODESEPARATOR" to segment the script into lexicographic sections for success checking. The proposed change aims to redefine OP_SUCCESS from making the entire script unconditionally valid to only making the current script segment unconditionally valid. This nuanced approach involves setting a "SUCCESS" flag to true upon encountering an OP_CODESEPARATOR, which, if followed by conditional success state settings, allows the script to succeed immediately under specific conditions. This method retains the practical benefits of the original OP_SUCCESS behavior while avoiding the complexity of adding new opcodes. - -Further insights were provided during discussions on the utility and potential modifications of SUCCESS codes within Bitcoin's scripting language. A notable contribution in this context is the idea of soft forking an existing OP_SUCCESSx opcode to become an "OP_WEAK_SUCCESS", aimed at utilizing the success semantics more effectively, especially not as a mere upgrade mechanism. This suggestion, nested within broader considerations about soft forking and upgrade mechanisms, highlights the adaptable nature of Bitcoin's scripting capabilities in response to evolving needs. + In recent discussions on the Bitcoin Development Mailing List, a new approach to script execution in Bitcoin's scripting system has been broached. The conversation was sparked by suggestions around modifying the behavior of scripts with respect to conditional success validation. Specifically, the dialogue revolved around the potential use of "OP_SEGMENT" as suggested by Rusty Russell, aiming to redefine the "OP_SUCCESS" functionality to facilitate more granular control over script validation. This proposed mechanism, leveraging "OP_CODESEPARATOR", seeks to make only specific segments of a script unconditionally valid, rather than the entire script. Such an adjustment would allow for a nuanced approach to script execution, where each segment before an "OP_CODESEPARATOR" is treated distinctly regarding its success validation. This proposal also introduces the concept of a "SUCCESS" flag, which plays a critical role in this nuanced execution method. -Additionally, the complexity and potential limitations of current scripting options are underscored by the challenges faced in implementing fraud proofs. The necessity of an "OP_SUCCESS" opcode emerges from scenarios where certain code executions indicate success without the need to run the remaining script—a crucial feature for writing efficient fraud proof scripts. However, emulating this functionality without a dedicated opcode proves cumbersome, as illustrated by a complex script transformation example. The discussion points towards a preference for integrating such an opcode directly into Bitcoin's script language to simplify development and enhance efficiency. +Further discussion highlighted the flexibility and strategic advantages offered by existing SUCCESSx codes in facilitating soft forks within the Bitcoin network. These codes are recognized for their foundational role in enabling upgrades without compromising the network’s stability. Andrew Poelstra's suggestion of transitioning one of these opcodes to an "OP_WEAK_SUCCESS" indicates a move towards utilizing these codes not just for network updates but for enhancing operational functionalities. This shift represents a broader perspective on developing the opcode infrastructure to cater to specialized applications while maintaining the integrity of the existing codebase. -The dialogue among Bitcoin developers reflects a continuous exploration of the script's capabilities and limitations, with a clear focus on refining the technology to better serve its users and developers. Through collaborative discussion and technical insights, the community seeks to navigate the intricacies of Bitcoin scripting to foster innovation and optimize performance. - 2024-12-09T22:06:00+00:00 +The utility of an "OP_SUCCESS" opcode was also elaborated upon, especially in the context of implementing fraud proofs in Bitcoin script. This opcode's functionality, allowing for immediate marking of script execution as successful, presents a significant advantage in scenarios requiring efficient identification of mismatches. Despite the potential for emulating this functionality through script rewriting, the complexity and inefficiency of such an alternative underscore the value of directly implementing "OP_SUCCESS". Tools exist for script rewriting, as indicated by a [GitHub resource](https://github.com/Bitcoin-Wildlife-Sanctuary/fraud-proof-compiler), yet they highlight the convoluted nature of achieving the same outcomes without a dedicated opcode. The conversation thus advocates for simplifying script development processes by incorporating opcodes like "OP_SUCCESS", aiming to enhance both efficiency and developer accessibility within the Bitcoin scripting environment. + 2024-12-12T05:49:00+00:00 diff --git a/static/bitcoin-dev/Dec_2024/m38456df1a8a1285cb993f027c7ab7a3bcec41a56_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml b/static/bitcoin-dev/Dec_2024/m38456df1a8a1285cb993f027c7ab7a3bcec41a56_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml new file mode 100644 index 000000000..720f92910 --- /dev/null +++ b/static/bitcoin-dev/Dec_2024/m38456df1a8a1285cb993f027c7ab7a3bcec41a56_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml @@ -0,0 +1,20 @@ + + + 1 + Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2024-12-13T02:43:09.174831+00:00 + + Weikeng Chen 2024-12-12 03:17:00+00:00 + + python-feedgen + + 1 + Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2024-12-13T02:43:09.174865+00:00 + + 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. + 2024-12-12T03:17:00+00:00 + + diff --git a/static/bitcoin-dev/Dec_2024/mfb23f4c0405bebff0a20a2e771f887002a9d191f_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml b/static/bitcoin-dev/Dec_2024/mfb23f4c0405bebff0a20a2e771f887002a9d191f_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml new file mode 100644 index 000000000..21395e7a6 --- /dev/null +++ b/static/bitcoin-dev/Dec_2024/mfb23f4c0405bebff0a20a2e771f887002a9d191f_Difficulty-in-emulating-weaker-OP-SUCCESS-and-why-it-should-be-a-real-opcode.xml @@ -0,0 +1,24 @@ + + + 1 + Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2024-12-13T02:43:00.985831+00:00 + + Brandon Black 2024-12-12 05:49:00+00:00 + + python-feedgen + + 1 + Difficulty in emulating "weaker" OP_SUCCESS and why it should be a real opcode + 2024-12-13T02:43:00.985863+00:00 + + 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. + 2024-12-12T05:49:00+00:00 + + diff --git a/static/delvingbitcoin/Dec_2024/3762_CTV-APO-CAT-activity-on-signet.xml b/static/delvingbitcoin/Dec_2024/3762_CTV-APO-CAT-activity-on-signet.xml new file mode 100644 index 000000000..9e820247b --- /dev/null +++ b/static/delvingbitcoin/Dec_2024/3762_CTV-APO-CAT-activity-on-signet.xml @@ -0,0 +1,28 @@ + + + 1 + CTV, APO, CAT activity on signet + 2024-12-13T02:37:34.391652+00:00 + + ajtowns 2024-12-12 05:57:47.375000+00:00 + + python-feedgen + + 1 + CTV, APO, CAT activity on signet + 2024-12-13T02:37:34.391721+00:00 + + 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. + 2024-12-12T05:57:47.375000+00:00 + + diff --git a/static/delvingbitcoin/Dec_2024/3763_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml b/static/delvingbitcoin/Dec_2024/3763_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml new file mode 100644 index 000000000..514dc92d6 --- /dev/null +++ b/static/delvingbitcoin/Dec_2024/3763_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml @@ -0,0 +1,20 @@ + + + 1 + Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions + 2024-12-13T02:38:22.991404+00:00 + + ariard 2024-12-12 06:42:46.666000+00:00 + + python-feedgen + + 1 + Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions + 2024-12-13T02:38:22.991436+00:00 + + 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. + 2024-12-12T06:42:46.666000+00:00 + + diff --git a/static/delvingbitcoin/Dec_2024/combined_CTV-APO-CAT-activity-on-signet.xml b/static/delvingbitcoin/Dec_2024/combined_CTV-APO-CAT-activity-on-signet.xml index d8bca3238..7fdea064a 100644 --- a/static/delvingbitcoin/Dec_2024/combined_CTV-APO-CAT-activity-on-signet.xml +++ b/static/delvingbitcoin/Dec_2024/combined_CTV-APO-CAT-activity-on-signet.xml @@ -2,15 +2,18 @@ 2 Combined summary - CTV, APO, CAT activity on signet - 2024-12-12T02:36:26.890474+00:00 + 2024-12-13T02:37:53.004159+00:00 - fiatjaf 2024-12-11 22:00:37.883000+00:00 + ajtowns 2024-12-12 05:57:47.375000+00:00 - fiatjaf 2024-12-11 21:56:21.895000+00:00 + fiatjaf . 2024-12-11 22:00:37.883000+00:00 - ajtowns 2024-12-11 11:49:09.953000+00:00 + fiatjaf . 2024-12-11 21:56:21.895000+00:00 + + + ajtowns . 2024-12-11 11:49:09.953000+00:00 fiatjaf . 2024-12-10 02:18:08.314000+00:00 @@ -36,6 +39,7 @@ ajtowns . 2024-11-14 17:34:11.568000+00:00 + @@ -51,19 +55,17 @@ 2 Combined summary - CTV, APO, CAT activity on signet - 2024-12-12T02:36:26.890560+00:00 + 2024-12-13T02:37:53.004247+00:00 - The development and testing of blockchain technologies, particularly within the Bitcoin ecosystem, have seen innovative explorations and experiments. One notable endeavor involved the creation of a spacechain intended to last for 100 years, as demonstrated in a demo with precomputed transactions initially stored by the miner. This project aimed at expanding the blockchain's capabilities, focusing on generating NFTs transferred between accounts via unique transaction types, `mint` and `transfer`. The mining process introduced an interesting model where users would pay miners through Lightning payments to publish transactions on the spacechain. This experiment, however, did not gain significant traction and was eventually discontinued, highlighting the challenges of garnering interest and engagement in new blockchain technologies. - -In another exploration, the use of APO (Anyprevout) as an overridable CTV (CheckTemplateVerify) showcased the potential for advanced blockchain functionalities. The Soma project, available on [GitHub](https://github.com/nbd-wtf/soma), provided a simplified demonstration of these capabilities, focusing on NFT transactions and blind merged-mining events compensated through signet lightning. Despite identifying vulnerabilities related to key path spending, these experiments underscored the experimental nature of such projects and their role in advancing blockchain technology understanding. + The conversation sheds light on the intricacies of blockchain technology, particularly focusing on the innovative use of spacechains and their potential to extend blockchain functionality. The initial discussion revolves around a demo project involving a precomputed blockchain designed to last for up to 1000 years, highlighting ambitions for long-term scalability. Despite efforts to engage users by running demo miners and spacechain nodes for several months, the project garnered minimal attention, with only about ten people interacting with it. This lack of engagement led to a reconsideration of the project's viability and the value of preserving the blockchain data, which facilitated the generation and transfer of NFTs without metadata between accounts through specific transaction types. -The analysis of CTV activity on ctv-signet revealed insights into the usage of different transaction types, including SegWit version 0, legacy, and taproot spends. This examination pointed out the challenges in capturing the full scope of taproot transactions due to their cryptographic properties. Skepticism around the utility of signet for assessing consensus mechanisms and development practices emerged, highlighting a preference among developers for regtest environments over signet for testing new features. +Further exploration into the technical aspects reveals an innovative approach to managing spacechain transactions using Lightning payments and replace-by-fee mechanisms. Miners played a crucial role in creating Lightning invoices for payment, which remained in-flight as they aggregated more transactions to fund an onchain transaction. The process involved intricate steps to resolve Lightning payments and release blocks or cancel specific transactions upon failure. A web interface served as a wallet, allowing users to track assets and interact directly with miners, showcasing the practical application of these technologies despite challenges encountered in implementation and user engagement. -Further contributions to the Bitcoin community include the development of a new tool for analyzing Inquisition transactions, aiming to enhance future investigations into such activities. The tool is detailed on [https://inquisition.observer](https://inquisition.observer). Additionally, the experimentation with pathcoin, specifically through `fidelitybonds.py` scripts, showcased before the San Salvador conference, emphasized the innovative applications of blockchain technology in controlled environments. +The discussion also delves into missed opportunities and reflections on the security and architectural decisions of the spacechain demonstration. Concerns were raised about not utilizing a NUMS point for the experiment, which could have allowed for a more secure and flexible code update mechanism. Additionally, the limitation to only 50 blocks due to a specific function call highlighted operational constraints and considerations for future projects. The conversation transitions into broader implications for blockchain technology, including the potential for spacechains to include new programming features and address scalability issues during fee spikes, albeit recognizing the challenges in achieving such advancements. -The diverse explorations into Bitcoin's technological advancements, such as soft forks and innovative transaction methodologies, demonstrate a nuanced landscape of development and user engagement. Projects like the simple-ctv-spacechain on GitHub and the creation of a CTV playground highlight the community's efforts to explore and test new capabilities. These initiatives, along with the practical application of concepts like joinpool and transactions demonstrating advanced scripting functionalities, exemplify the ongoing endeavors to enhance Bitcoin's ecosystem. +Attention is drawn to recent developments in blockchain technology, like the application of APO as an overridable CTV and the experimentation with pathcoin, underscoring ongoing innovation within the field. These explorations highlight the capabilities of blockchain for facilitating secure and verifiable transactions, while also acknowledging vulnerabilities and the experimental nature of these projects. The discussion emphasizes the importance of Signet in providing a testing ground for innovations and the critical role of comprehensive testing environments in ensuring the correct behavior of 'rare case' scenarios. -Bitcoin Improvement Proposals (BIPs) 118, 119, and 347 significantly impacted scripting capabilities, introducing flexible transaction signing, complex spend conditions, and sophisticated contract structures. These developments, observed through transactions on signet, indicate a strategic application of new features for secure and functional enhancements in Bitcoin scripting. The tracking of these innovations, involving modifications to signet nodes' validation processes, reflects the community's commitment to exploring and utilizing advanced scripting options for varied and secure applications within the Bitcoin network. - 2024-12-11T22:00:37.883000+00:00 +Moreover, the analysis of CTV activity and the utility of signet for assessing network consensus raises questions about the methodologies used to gauge technological adoption within the Bitcoin ecosystem. The correspondence concludes with a mention of a new tool designed for analyzing Bitcoin Inquisition transactions, signaling continuous efforts to enhance the understanding and functionality of blockchain technologies. This conversation encapsulates the dynamic and evolving landscape of blockchain development, characterized by experimental initiatives, technical challenges, and the pursuit of long-term scalability and security improvements. + 2024-12-12T05:57:47.375000+00:00 diff --git a/static/delvingbitcoin/Dec_2024/combined_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml b/static/delvingbitcoin/Dec_2024/combined_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml new file mode 100644 index 000000000..1fda11463 --- /dev/null +++ b/static/delvingbitcoin/Dec_2024/combined_Disclosure-irrevocable-fees-stealing-from-LN-using-revoked-commitment-transactions.xml @@ -0,0 +1,29 @@ + + + 2 + Combined summary - Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions + 2024-12-13T02:38:38.542047+00:00 + + ariard 2024-12-12 06:42:46.666000+00:00 + + + harding . 2024-12-11 00:18:59.444000+00:00 + + + + python-feedgen + + 2 + Combined summary - Disclosure: irrevocable fees---stealing from LN using revoked commitment transactions + 2024-12-13T02:38:38.542086+00:00 + + In the realm of blockchain technology, particularly within the Lightning Network (LN), a critical vulnerability was identified that allowed for the potential misappropriation of up to 98% of a channel's funds by miners. This issue was not limited to malicious actions but could also manifest during regular operations, with losses generally falling below the maximum possible impact. It was discovered across major LN implementations such as Eclair, LDK, and LND under their default settings, including Core Lightning when operated with specific configurations that bypass fee limits. The flaw is rooted in the manipulation of offchain LN commitment transactions by reallocating balances and adjusting fees to divert the bulk of funds upon transaction confirmation. + +To combat this vulnerability, updates have been deployed across various LN implementations, with each aiming to mitigate the risk by tightening controls over transaction fees. Despite these efforts, the potential for exploitation remains due to the variable nature of onchain transaction fees. Addressing this issue thoroughly requires modifications at both the LN protocol level and within Bitcoin's peer-to-peer transaction relay mechanisms. The suggested remedies involve capping the amount that can be allocated to transaction fees and moving towards fixed commitment fees to eliminate the vulnerability permanently. However, these solutions call for significant updates to the protocols, including the implementation of reliable package relay for Bitcoin and adjustments to the LN protocol. + +The discovery and subsequent resolution process underscored the collaborative effort among LN implementation maintainers and highlighted the complexities involved in managing fee dynamics in offchain contract protocols. This incident has spurred ongoing discussions within the Bitcoin and LN communities aimed at simplifying and strengthening the management of transaction fees, thereby enhancing the security and resilience of offchain payment channels. Detailed information about the vulnerability and the steps taken to address it can be found through various resources, including [Eclair 2815](URL), [Eclair v0.10.0](URL), [LDK 3045](URL), [LDK 0.0.123](URL), [LND 8824](URL), and [LND 0.18.3-beta](URL). + +Furthermore, an analysis of the historical deployment of feerate limits reveals that such measures were initially implemented to counter vulnerabilities linked to "irrevocable fees" by setting upper bounds on acceptable feerates from channel counterparts. These safeguards, introduced following mitigations against "excessive trimmed HTLCs / dust HTLC exposure," facilitated easier calculation of the worst-case msat denominated dust HTLCs exposure from varied scenarios since 2021. Additionally, the Validating Lightning Signer (VLS) has consistently included a `validate_fee()` check from its pre-production release to vet proposed feerates against a maximum threshold, addressing concerns related to "miner-fee-siphoning attacks." This preventive approach indicates a proactive stance towards securing transactions within the LN framework, demonstrating the evolving measures taken to shield network participants from emerging threats. + 2024-12-12T06:42:46.666000+00:00 + + diff --git a/static/delvingbitcoin/Nov_2024/combined_CTV-APO-CAT-activity-on-signet.xml b/static/delvingbitcoin/Nov_2024/combined_CTV-APO-CAT-activity-on-signet.xml index d8bca3238..7fdea064a 100644 --- a/static/delvingbitcoin/Nov_2024/combined_CTV-APO-CAT-activity-on-signet.xml +++ b/static/delvingbitcoin/Nov_2024/combined_CTV-APO-CAT-activity-on-signet.xml @@ -2,15 +2,18 @@ 2 Combined summary - CTV, APO, CAT activity on signet - 2024-12-12T02:36:26.890474+00:00 + 2024-12-13T02:37:53.004159+00:00 - fiatjaf 2024-12-11 22:00:37.883000+00:00 + ajtowns 2024-12-12 05:57:47.375000+00:00 - fiatjaf 2024-12-11 21:56:21.895000+00:00 + fiatjaf . 2024-12-11 22:00:37.883000+00:00 - ajtowns 2024-12-11 11:49:09.953000+00:00 + fiatjaf . 2024-12-11 21:56:21.895000+00:00 + + + ajtowns . 2024-12-11 11:49:09.953000+00:00 fiatjaf . 2024-12-10 02:18:08.314000+00:00 @@ -36,6 +39,7 @@ ajtowns . 2024-11-14 17:34:11.568000+00:00 + @@ -51,19 +55,17 @@ 2 Combined summary - CTV, APO, CAT activity on signet - 2024-12-12T02:36:26.890560+00:00 + 2024-12-13T02:37:53.004247+00:00 - The development and testing of blockchain technologies, particularly within the Bitcoin ecosystem, have seen innovative explorations and experiments. One notable endeavor involved the creation of a spacechain intended to last for 100 years, as demonstrated in a demo with precomputed transactions initially stored by the miner. This project aimed at expanding the blockchain's capabilities, focusing on generating NFTs transferred between accounts via unique transaction types, `mint` and `transfer`. The mining process introduced an interesting model where users would pay miners through Lightning payments to publish transactions on the spacechain. This experiment, however, did not gain significant traction and was eventually discontinued, highlighting the challenges of garnering interest and engagement in new blockchain technologies. - -In another exploration, the use of APO (Anyprevout) as an overridable CTV (CheckTemplateVerify) showcased the potential for advanced blockchain functionalities. The Soma project, available on [GitHub](https://github.com/nbd-wtf/soma), provided a simplified demonstration of these capabilities, focusing on NFT transactions and blind merged-mining events compensated through signet lightning. Despite identifying vulnerabilities related to key path spending, these experiments underscored the experimental nature of such projects and their role in advancing blockchain technology understanding. + The conversation sheds light on the intricacies of blockchain technology, particularly focusing on the innovative use of spacechains and their potential to extend blockchain functionality. The initial discussion revolves around a demo project involving a precomputed blockchain designed to last for up to 1000 years, highlighting ambitions for long-term scalability. Despite efforts to engage users by running demo miners and spacechain nodes for several months, the project garnered minimal attention, with only about ten people interacting with it. This lack of engagement led to a reconsideration of the project's viability and the value of preserving the blockchain data, which facilitated the generation and transfer of NFTs without metadata between accounts through specific transaction types. -The analysis of CTV activity on ctv-signet revealed insights into the usage of different transaction types, including SegWit version 0, legacy, and taproot spends. This examination pointed out the challenges in capturing the full scope of taproot transactions due to their cryptographic properties. Skepticism around the utility of signet for assessing consensus mechanisms and development practices emerged, highlighting a preference among developers for regtest environments over signet for testing new features. +Further exploration into the technical aspects reveals an innovative approach to managing spacechain transactions using Lightning payments and replace-by-fee mechanisms. Miners played a crucial role in creating Lightning invoices for payment, which remained in-flight as they aggregated more transactions to fund an onchain transaction. The process involved intricate steps to resolve Lightning payments and release blocks or cancel specific transactions upon failure. A web interface served as a wallet, allowing users to track assets and interact directly with miners, showcasing the practical application of these technologies despite challenges encountered in implementation and user engagement. -Further contributions to the Bitcoin community include the development of a new tool for analyzing Inquisition transactions, aiming to enhance future investigations into such activities. The tool is detailed on [https://inquisition.observer](https://inquisition.observer). Additionally, the experimentation with pathcoin, specifically through `fidelitybonds.py` scripts, showcased before the San Salvador conference, emphasized the innovative applications of blockchain technology in controlled environments. +The discussion also delves into missed opportunities and reflections on the security and architectural decisions of the spacechain demonstration. Concerns were raised about not utilizing a NUMS point for the experiment, which could have allowed for a more secure and flexible code update mechanism. Additionally, the limitation to only 50 blocks due to a specific function call highlighted operational constraints and considerations for future projects. The conversation transitions into broader implications for blockchain technology, including the potential for spacechains to include new programming features and address scalability issues during fee spikes, albeit recognizing the challenges in achieving such advancements. -The diverse explorations into Bitcoin's technological advancements, such as soft forks and innovative transaction methodologies, demonstrate a nuanced landscape of development and user engagement. Projects like the simple-ctv-spacechain on GitHub and the creation of a CTV playground highlight the community's efforts to explore and test new capabilities. These initiatives, along with the practical application of concepts like joinpool and transactions demonstrating advanced scripting functionalities, exemplify the ongoing endeavors to enhance Bitcoin's ecosystem. +Attention is drawn to recent developments in blockchain technology, like the application of APO as an overridable CTV and the experimentation with pathcoin, underscoring ongoing innovation within the field. These explorations highlight the capabilities of blockchain for facilitating secure and verifiable transactions, while also acknowledging vulnerabilities and the experimental nature of these projects. The discussion emphasizes the importance of Signet in providing a testing ground for innovations and the critical role of comprehensive testing environments in ensuring the correct behavior of 'rare case' scenarios. -Bitcoin Improvement Proposals (BIPs) 118, 119, and 347 significantly impacted scripting capabilities, introducing flexible transaction signing, complex spend conditions, and sophisticated contract structures. These developments, observed through transactions on signet, indicate a strategic application of new features for secure and functional enhancements in Bitcoin scripting. The tracking of these innovations, involving modifications to signet nodes' validation processes, reflects the community's commitment to exploring and utilizing advanced scripting options for varied and secure applications within the Bitcoin network. - 2024-12-11T22:00:37.883000+00:00 +Moreover, the analysis of CTV activity and the utility of signet for assessing network consensus raises questions about the methodologies used to gauge technological adoption within the Bitcoin ecosystem. The correspondence concludes with a mention of a new tool designed for analyzing Bitcoin Inquisition transactions, signaling continuous efforts to enhance the understanding and functionality of blockchain technologies. This conversation encapsulates the dynamic and evolving landscape of blockchain development, characterized by experimental initiatives, technical challenges, and the pursuit of long-term scalability and security improvements. + 2024-12-12T05:57:47.375000+00:00