Published on: 2022-04-28T12:23:32+00:00
In a discussion on the Bitcoin scripting language, a member raised a question about the necessity of using DROP/1 when leaving a 32-byte hash on the stack. Another member clarified that it may not necessarily mean everyone is using Sapio to construct transactions, but they may be using sapio-miniscript or a different miniscript implementation compatible with sapio-miniscript's CTV fragment. The use of miniscript seems different than using Sapio, but the underlying point of the discussion remains unchanged.The conversation then shifted to the potential benefits of using bare CTV over segwit v0/v1. It was noted that bare CTV can save 34 or 67 bytes per histogram bucket, allowing for more buckets and greater feerate savings. Binning into 5 groups yields a higher feerate discount compared to binning into 4 groups. However, the knock-on effects of these changes are difficult to predict accurately. The cheapness of nodes in the graph can change the optimal graph and make simple comparisons inadequate. Bugs like nonstandard broadcasting would be fixed through testing, and the proposed changes are still in the "interesting thought experiment" stage.Regarding the use of bare CTV, it was mentioned that it only saves bytes when spending, and an extra 34 or 67 bytes of witness data is fairly immaterial. Real user data suggests that nobody will benefit from using bare CTV. Upgrading old hardware may be necessary to support new features. The potential benefits of using segwit v0 CTV for users with hardware modules or MPC Threshold Crypto that only support ECDSA signatures were also discussed.In the discussion on the bitcoin-dev mailing list, various participants shared their thoughts on the use of bare CTV in different contexts. Testing was emphasized as a crucial step in identifying bugs and ensuring consistency with proposed consensus and policy rules. The benefits of bare CTV were explored, including its potential to save space when batching transactions for customers with different fee priority levels. However, it was noted that real user data suggests that nobody will benefit from using bare CTV. The possibility of using OP_SUCCESSx in segwitv0 CTV was discussed, but it was concluded that upgrading old hardware may be necessary to support new features.The discussion on Consensus-enforced Transaction Verification (CTV) in Bitcoin highlighted the importance of testing and demonstrating major use cases before implementing new features. While there are working prototypes of CTV's use cases, they are not yet production-ready. The potential benefits of CTV were explored, such as combining batches into a root and N batch outputs, eliminating the need for inputs, signatures, and change outputs per batch. However, the limitations and additional blockspace usage of bare-CTV were questioned. The use of an OP_SUCCESS code from tapscript instead of bare-CTV was suggested as a better alternative. The justification for bare-CTV and its limitations were further discussed.A recent email thread focused on the testing and implementation of new feature proposals. The criteria for soft-forking a proposal into consensus code were discussed, emphasizing the need for real-life use cases and sufficient testing. CheckTemplateVerify (CTV), a feature enabling more complex smart contracts, was examined. While there are prototypes of CTV's major use cases, they are not yet production-ready. Sapio was highlighted as an example of CTV's versatility. The discussion also touched on other proposed features such as eltoo and TLUV, noting their current status and design considerations. It was suggested that consensus should not be rushed until use cases are fully fleshed out and demonstrated.In a bitcoin-dev post, the importance of decision making and testing before implementing changes was emphasized. The significance of hard numbers and clear metrics for evaluating proposals was questioned. The readiness and eagerness to use CheckTemplateVerify (CTV) and Taproot were compared. The usefulness of bare-CTV and its limitations were discussed, along with alternative options like using an OP_SUCCESS code from tapscript. The writer suggested defining clear metrics for evaluating proposals to facilitate decision making.In a discussion on the bitcoin-dev mailing list, a member questioned the necessity of DROP/1 in a specific context. Another participant explained that with Taproot's CLEANSTACK rule, leaving the 32-byte hash on the stack would not evaluate as true. The conversation also touched on the use of CastToBool() function in tapscript and the relevance of the MINIMALIF rule to CTV.Overall, the discussions revolve around the potential benefits, limitations, and testing of Consensus-enforced Transaction Verification (CTV) in Bitcoin. Various perspectives on the use of bare CTV, alternative implementations, and the need for clear metrics are presented.In a recent email thread on the bitcoin-dev mailing list, the lack of practical experimentation with CheckTemplateVerify (CTV) was discussed.
Updated on: 2023-08-02T05:39:40.983139+00:00