delvingbitcoin

Covenant tools softfork

Covenant tools softfork

Original Postby David Harding

Posted on: September 29, 2023 20:31 UTC

The email discusses several proposed features and improvements for Bitcoin, highlighting the balance between introducing specific functionalities for unproven use cases versus enabling a more general set of capabilities that could foster innovation without waiting for consensus changes.

Among the mentioned proposals are vaults, which enhance custodial security through reactive measures, and can currently be implemented with presigned transactions albeit with limitations. The concept of LN-Symmetry aims to adjust penalty assignments in multi-party scenarios without needing a consensus change, suggesting that existing protocols like John Law's tunable penalties might offer similar benefits.

Efficient implementations of Discreet Log Contracts (DLCs) focus on reducing offchain operation requirements without significantly impacting their onchain footprint, despite DLCs suffering from poor scalability due to their need for onchain anchoring for every trade. Non-interactive channel openings and congestion control concepts are also discussed, with the former potentially achievable through existing mechanisms like CTV with comparable onchain costs, and the latter requiring payment batching which remains underutilized.

Decentralized mining pools are touched upon, noting that Stratum v2 offers a pathway towards decentralization that is not widely adopted. Various Lightning Network (LN) efficiency improvements are considered valuable, especially if they simplify highly used code. The use of covenant-based timeout trees for scaling Lightning, building on previous protocols for more capital-efficient and user-friendly channel factories, is acknowledged as a step forward, although it does not require consensus changes for implementation.

The writer expresses a preference for enabling a broad set of features that allow for the creation and deployment of scripts akin to those proposed, even if less efficiently, to avoid delaying innovation until specific consensus changes are agreed upon. This approach would circumvent the potential risks associated with waiting for new opcodes or sighashes that are infrequently used or support specialized functions that may not see significant adoption. A suggested stub proposal includes OP_CSFS + OP_CAT, or variations thereof, to facilitate any desired transaction introspection, acknowledging the risks of recursive covenants and Miner Extractable Value (MEV) scenarios but emphasizing the importance of not stifling development by overly relying on limited opcode additions.