Author: Antoine Riard 2022-07-23 16:41:55
Published on: 2022-07-23T16:41:55+00:00
Antoine Riard, a Bitcoin developer, has proposed a new covenant open specification process on the bitcoin-dev mailing list. He believes that although discussions on covenants have been prolific and intense, they have not yet reached a consensus on any new set of contracting primitives satisfying the requirements of known covenant-enabled use-cases.Riard proposes regular meetings with an open agenda to collect, pseudo-specify, and find champions for known use-cases with no timeframe. He notes that there would be rotating meeting chairs and multiple covenant documentation archivists. Riard also emphasizes the need for technical evaluation of any covenant proposal on a range of criteria such as scalability, efficiency, simplicity, extensibility, robustness, data confidentiality, etc.Riard believes that if we retain a covenant definition, which is a spending constraint restricting the transaction to which the spent UTXO can be spent, and enabling to program contracts/protocols at the transaction-level instead of the script-level, then the list of Script primitives proposed during the last years has grown large. The proposed Script primitives extend the range of workable multi-party contract protocols. The problem-space offered by covenants is abundant, offering vast extensions of the capabilities of Bitcoin as a system, i.e enabling new types of multi-party contract protocols.Riard proposes that the task of technical evaluation of any covenant proposal sounds at least two-fold. There is first reasoning about the enabled protocols on a range of criteria such as scalability, efficiency, simplicity, extensibility, robustness, data confidentiality, etc. Though once this step is achieved, there is still more reasoning work to evaluate how good a fit is a proposed Script primitive, the efficiency/simplicity/ease to use trade-offs, but also if there are no functionality overlap or hard constraints on the use-cases design themselves or evolvability w.rt future Script extensions or generalization of the opcode operations.In a recent post on the Bitcoin-dev mailing list, Antoine Riard expressed interest in kick-starting a covenant specification process. Covenants are required building blocks to enable scalable payments pools designs like CoinPool. Riard notes that the hard part isn't coming up with the best technical solution to a set of problems, but in the iterative process where all voices are listened to reach consensus on what is actually meant by "best" and if the problems are accurate.Riard would appreciate feedback on what the ideal covenant specification process looks like. He provides links to multiple resources, including BIP-118, which specifies a new opcode called OP_CHECKSIGFROMSTACK, and BIP-119, which introduces Congestion Controlled Transactions. Other resources include papers on advanced contracts, Taproot, spacechains, mempool work, and smart contracts. Riard acknowledges that there are still holes to patch in LN, and he's fine with waiting until the community agrees that it's the right time for a covenant process. He cautions that no process can guarantee community consensus at the end of it, especially if some of those who we consider experts in this area only tentatively participate.
Updated on: 2023-06-15T23:08:43.952156+00:00