Posted by stevenroose
Mar 13, 2025/16:40 UTC
The discussion revolves around the deployment of taproot and its implications on future consensus upgrades, specifically focusing on Conditional Transaction Outputs (CTV) and CheckTemplateVerify (CTV) alongside CoinSwap Feature Set (CSFS). The concern raised points towards a shift in the criteria for accepting soft fork upgrades from technical merit to practical usage. This shift raises questions about whether the technical merits of CTV and CSFS are overlooked or deemed insufficient without evident practical application. Furthermore, it's highlighted that if a project cannot attract even one dedicated individual willing to invest time into what is considered a "moonshot" project, its feasibility and potential impact might be overestimated.
A significant point of contention mentioned is the portrayal of "covenants" within CTV’s description, particularly the concern around "recursive covenants" which seem to clash with the co-activation of CSFS. It's suggested that a straightforward initial step could be to amend BIP 119 to address these concerns more accurately. However, there's an expressed frustration regarding the focus on the motivational section of the BIP, questioning the constructive nature of such a critique. An alternative proposition involves discarding BIP 119 entirely in favor of a new proposal that could potentially offer a more efficient solution through a simplified TXHASH BIP, although this idea seems to suffer from a lack of feedback and engagement from the community.
The conversation also touches upon the practical limitations of using CTV in specific scenarios, such as Liquid's pegin addresses system. It's argued that while CTV may not suit situations where users need to send varying amounts to a single address, it functions well when transactions are managed by software. This approach could eliminate the need for certain interactions, making fund recovery possible via mnemonic phrases, something currently unachievable due to the necessity of cosignature in transaction exits. Additionally, it's noted that while TXHASH can ensure input and output amounts match in single-input transactions, it falls short in scenarios requiring the sum of multiple inputs to equal the sum of outputs, indicating a possible area for further development or consideration.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback