Author: Jeremy 2022-01-11 03:42:50
Published on: 2022-01-11T03:42:50+00:00
The response is a review and feedback on the implementation of a BIP (Bitcoin Improvement Proposal) for Congestion-Controlled Transactions (CTV). The author acknowledges some difficulties with the review process, including confusion over which branch of the code to review. There is a discrepancy between the BIP and the implementation regarding caching and Denial of Service (DoS) protection but assures that this was an intentional design goal and will add a note to the BIP to clarify the importance of caching.The author discusses use cases for CTV, including Congestion Controlled Transactions, Wallet Vaults, Payment Channels, and CoinJoin. While these use cases are not fully fleshed out in the BIP, there have been implementations of Vaults using CTV, and Lightning-specific wallets plan to use CTV to batch-open channels. The author notes that CTV trees may result in more transactions, but CTV allows for the deferral of the utilization of chainspace, and it opens the opportunity for cooperation through payment pools.The author also addresses concerns about covenant design trade-offs and risks and notes that the covenant must be entirely known in advance. There is a risk of fungibility issues with covenants, but CHECKTEMPLATEVERIFY approaches are restricted to simple templates, limiting potential risks. Overall, the response clarifies some issues with the review process and provides additional information on use cases and design considerations for CTV.In the discussion, safety concerns are raised regarding templated transactions. While they expand in a finite number of steps, making them as safe as transactions that create all inputs directly, the concern arises when the "finite" number of steps could be millions of transactions, making it "infinitely long" for any practical purpose. Currently, testing for these transactions is poorly documented without clear goals regarding edge cases being tested. It is suggested that test vectors should be used to explicitly write down the data in the form of serialized transactions that are fed into the consensus engine to avoid mistakes in test coverage due to broken test harnesses.
Updated on: 2023-06-15T04:17:00.840996+00:00