Published on: 2022-10-07T15:33:12+00:00
The bitcoin-dev mailing list recently discussed the potential uses and benefits of colored coins, which allow for coins whose validity can be verified on chain. These colored coins could be used to tokenize real-world assets and create new forms of decentralized applications. Antoine Riard proposed an open, decentralized process for investigating problem and solution spaces, involving IRC as a platform for discussion and in-person meetups to cut through misunderstandings. The group would go through six phases, defining motivations and constraints, evaluating proposals, and reaching consensus. Results would be published for community feedback.Antoine Riard asked for the definition and examples of capabilities in the context of Bitcoin. Examples include payments to vaults with specific restrictions, oracles with verifiable validity on the chain, and colored coins associated with a specific color. The conversation on the bitcoin-dev mailing list focused on starting a covenant process from the use-cases themselves and analyzing trade-offs. Proposed use-cases for Bitcoin's capabilities include multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities should be included in a covenants proposal was raised.In a recent email exchange, the writer raised concerns about using economic simulations or other cryptocurrencies to gather feedback on script extensions. They proposed a covenant working group/process that focuses on collecting use-cases, analyzing trade-offs, and designing adequate covenants. They suggested creating a smart contracts unchained platform with a richer language to prototype new `OP_` codes. The writer emphasized the importance of higher standards in Bitcoin development and suggested evolving engineering standards through consensus-driven methods.ZmnSCPxj responded to Antoine's suggestion of claiming Taproot history as a standard methodology in Bitcoin development. They argued that Bitcoin development methodology is still an open problem and suggested examining more agile approaches. They proposed creating a generic contracting platform with a richer language to prototype new `OP_` codes or change the behavior of existing ones. The Bitcoin consensus layer was compared to hardware, and the idea of adding a softer layer without compromising the hard layer was discussed.In a discussion on programmable vaults, Bram Cohen proposed using covenants to impose rules for spending transactions. These rules could include requirements for spending outputs only if they are claimed by a transaction that spends it as a whole or if the output is P2SH with a specified script pattern. Programmable vaults are one of several proposed use-cases for Bitcoin's capabilities. The question of whether capabilities should be in scope for a covenants proposal was raised.Antoine Riard discussed the range of use cases for covenants proposals, including multi-party stateful contracts, congestion trees, payment pools, and more. The question of whether capabilities are in scope for a covenant proposal was raised, specifically regarding vaults working better when payments to them are immediately locked up.Antoine Riard proposed a covenant effort to advance covenant and contracting knowledge, collect use-cases, and explore the problem space. Technical evaluation of covenant proposals on criteria such as scalability, efficiency, simplicity, and data confidentiality was emphasized. A separate post mentioned the need for higher standards in Bitcoin development and the importance of documentation and communication. Agile approaches and good engineering practices were discussed.Antoine Riard proposed a covenant open specification process to collect use-cases, find champions, and evaluate covenant proposals. Technical evaluation would consider scalability, efficiency, simplicity, extensibility, and more. The task of evaluating covenant proposals involves reasoning about enabled protocols and evaluating the fit of proposed Script primitives. Feedback on the ideal covenant specification process was requested.Overall, the discussions on the bitcoin-dev mailing list revolved around exploring the potential uses and benefits of colored coins, proposing an open and decentralized process for investigating problem and solution spaces, defining capabilities in the Bitcoin context, raising concerns about feedback gathering methods, discussing higher standards and engineering practices in Bitcoin development, and proposing a covenant specification process to advance covenant and contracting knowledge. The range of use-cases for covenants proposals was also discussed, along with the question of whether capabilities should be included in a covenants proposal.Antoine Riard has proposed a new covenant open specification process for Bitcoin in an email to the bitcoin-dev mailing list. Riard acknowledges that there are still gaps to be addressed in the Lightning Network (LN) and suggests waiting until the community agrees on the right time for a covenant process. However, he cautions that no process can guarantee community consensus, especially if experts only tentatively participate.The author of the email proposes online meetings on IRC as an alternative to in-person meetings, allowing for more open discussions and better understanding of complex topics. They also suggest restarting the Scaling Bitcoin conferences twice a year to keep up with the rapidly evolving scaling landscape.
Updated on: 2023-08-02T07:05:21.717413+00:00