From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B4E1DC002D for ; Wed, 20 Jul 2022 20:42:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 79A9581A46 for ; Wed, 20 Jul 2022 20:42:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 79A9581A46 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=dy6rYsti X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Tbyo1kyKkX for ; Wed, 20 Jul 2022 20:42:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 98FD681A0D Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by smtp1.osuosl.org (Postfix) with ESMTPS id 98FD681A0D for ; Wed, 20 Jul 2022 20:42:54 +0000 (UTC) Received: by mail-il1-x134.google.com with SMTP id d4so9897979ilc.8 for ; Wed, 20 Jul 2022 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=fFIqXa0wfhM0IPc4j6BQcT8dRb4bUaWugLQ+OafsWbs=; b=dy6rYstiTFjD7/7btfgaf34ADZm2a6jnAcRB38j/Dtv2sCuDVkwMpY7e6rSVrsjisY EVbq8JR5YjcQM8vXerRYwXZY5189oUg6Sz7L4Hnjehf20apgKwc96UTh4AKSgY14AeQl npzH4FitNeDq30n3txp8s8qGmw/X6qQ0TJE99eP7kNYzd5Ig6XZqsaqXQIhSATzKN9Wz uS5YPhbYeyEJLmOkz0LTntLn/UyTDOkj6684Sx3u3x2XgfRwxc2ySsJD4K/P0j4CH1Lf 1dmsb8GFDfH9IRkEdQy/N2WLMwYNVCCr5oTqqgJOQruUU1+82W/si8We7ewtIOfsxZ1j nkKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fFIqXa0wfhM0IPc4j6BQcT8dRb4bUaWugLQ+OafsWbs=; b=6KqJaCi1+aSExUmVsKIG9gIGXw2ADTzxPNFzYa2uoz2YsCkP5ihWxnmTetuXlQVfxg vgPVW/+ETW3ZGB3vveH/LM1ogoHcFBKMSFfMCRqjAeDoaU2oKO7mOQT7W5ofM0NgSJQ8 MhQwZiL5a0QRmPjPivU6fCRNWdUEaZAg33AXFPVjqR1MhbxQsUMRnW4oXnIH5lIAApwy oh6B6QyeYIZqtlgchP788acvaECYBmGWtA66wp4MHlNm8aiTMzuw3kihkTu2CmKptf9i NXOwcyNtK17HVbgfFwEt0GBKQIeUDlPqXEVIed3coDX9nHgRE3AIyV9BOl2fDfzxWitL Iwhg== X-Gm-Message-State: AJIora+Tl8GkqnPKhLlKKpjHBnRwTe4uLHk2zUSfDeT+fg5Wbch6yVmO maCkB+W27NfqY3AgWWapeFr+UIMU7xR35OLaVCyVIJkbFnA= X-Google-Smtp-Source: AGRyM1sRgSFIWKwGaDQKLRHeQGvrsd50o2m03ieJCLEZrcWH2K2F29tYj6hDujvDhd74SC7b+AJwdMCwejXuyXxcD18= X-Received: by 2002:a05:6e02:18c7:b0:2dc:404a:8416 with SMTP id s7-20020a056e0218c700b002dc404a8416mr20174116ilu.39.1658349773359; Wed, 20 Jul 2022 13:42:53 -0700 (PDT) MIME-Version: 1.0 From: Antoine Riard Date: Wed, 20 Jul 2022 16:42:42 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000278ffa05e442a563" X-Mailman-Approved-At: Wed, 20 Jul 2022 21:46:02 +0000 Subject: [bitcoin-dev] On a new community process to specify covenants X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2022 20:42:56 -0000 --000000000000278ffa05e442a563 Content-Type: text/plain; charset="UTF-8" Hi, Discussions on covenants have been prolific and intense on this mailing list and within the wider Bitcoin technical circles, I believe however without succeeding to reach consensus on any new set of contracting primitives satisfying the requirements of known covenant-enabled use-cases. I think that's a fact to deplore as covenants would not only offer vast extensions of the capabilities of Bitcoin as a system, i.e enabling new types of multi-party contract protocols. But also empowering Bitcoin on its fundamental value propositions of store of value (e.g by making vaults more flexible) and payment system (e.g by making realistic channel factories/payment pools). If we retain as a covenant definition, 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, the list of Script primitives proposed during the last years has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all the listed primitives are at different states of formalization, some already fully fleshed-out in BIPs, other still ideas on whiteboard, yet they all extend the range of workable multi-party contract protocols. Indeed this range has grown wild. Without aiming to be exhaustive (I'm certainly missing some interesting proposals lost in the abyss of bitcointalk.org), we can mention the following use-cases: multi-party stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" layered commitments [14], programmable vaults [15], multi-events contracts [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral lending [19], ... Minding all those facts, I would say 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 criterias such as scalability, efficiency, simplicity, extensibility, robustness, data confidentiality, etc. Asking questions like what are the interactions between layers, if any ? Or how robust is the protocol, not just interactivity failure between participant nodes but in the face of mempools spikes or internet disruption ? Or if the performance is still acceptable on shared resources like blockspace or routing tables if everyone is using this protocol ? Or if the protocol minimizes regulatory attack surface or centralization vectors ? 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. Moreover, if you would like your evaluation of a covenant proposal to be complete, I don't believe you can squeeze the implications with the mempool rules and combination with any consistent fee-bumping strategy. To say things politely, those areas have been a quagmire of vulnerabilities, attacks and defects for second-layers Bitcoin protocols during the last years [20]. Considering the abundant problem-space offered by covenants, I believe there is a reasonable groundwork to pursue in building the use-cases understanding (e.g prototype, pseudo-specification, documentation, ...) and building consensus on the framework of criterias on which to evaluate them [21]. It might raise a really high bar for any covenant proposal compared to previous softforks, however I think it would adequately reflect the growth in Bitcoin complexity and funds at stakes during the last years. Moving towards this outcome, I would like to propose a new covenant open specification process, in the same spirit as we have with the BOLTs or dlcspecs. We would have regular meetings (biweekly/monthly ?), an open agenda where topics of discussion can be pinned in advance and documentation artifacts would be built with time driven by consensus (e.g 1st phase could be to collect, pseudo-specify and find champion(s) for known use-cases ?) and no timeframe. Starting date could be September / October / November (later, 2023 ?), giving time for anyone interested in such a covenant process to allocate development and contribution bandwidth in function of their involvement interest. Learning from the good but specially from the bad with setting up the L2 onchain support meetings last year, I think it would be better to keep the agenda open, loose and free as much we can in a "burn-the-roadmap" spirit, avoiding to create a sense of commitment or perceived signaling in the process participants towards any covenant solution. I would guess things to be experimental and evolutionary and folks to spend the first meetings actually to express what they would like the covenant process to be about (and yes that means if you're a domain expert and you find the pace of things too slow sometimes, you have to learn to handle your own frustration...). In a "decentralize-everything" fashion, I believe it would be good to have rotating meeting chairs and multiple covenant documentation archivists. I'm super happy to spend the time and energy bootstrapping well such covenant process effort, though as it's Bitcoin learn to decentralize yourself. I'm really curious what the outcome of such a covenant process would look like. We might end up concluding that complex covenants are too unsafe by enabling sophisticated MEV-attacks against LN [22]. Or even if there is an emergent technical consensus, it doesn't mean there is a real market interest for such covenant solutions. That said, I'm not sure if it's really a subject of concern when you're reasoning as a scientist/engineer and you value technical statements in terms of accuracy, systematic relevance and intrinsic interest. Overall, my motivation to kick-start such a process stays in the fact that covenants are required building blocks to enable scalable payments pools design like CoinPool. I believe payments pools are a) cool and b) a good shot at scaling Bitcoin as a payment system once we have reached scalability limits of Lightning, still under the same security model for users. However, as a community we might sense it's not the good timing for a covenant process. I'm really fine with that outcome as there are still holes to patch in LN to keep me busy enough for the coming years. Zooming out, I believe with any discussion about covenants or other soft forks, the hard part isn't about coming up with the best technical solution to a set of problems but in the iterative process where all voices are listened to reach (or not) consensus on what is actually meant by "best" and if the problems are accurate. The real physics of Bitcoin is the physics of people. It's a work of patience. Anyways, eager to collect feedbacks on what the ideal covenant specification process looks like. As usual, all opinions and mistakes are my own. Cheers, Antoine [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki [1] https://bitcoinops.org/en/topics/op_checksigfromstack/ [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html [9] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki [11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html [12] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions [13] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html [14] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf [16] https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf [17] https://blog.bitmex.com/taproot-you-betcha/ [18] https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef [20] https://github.com/jamesob/mempool.work [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806 [22] https://blog.bitmex.com/txwithhold-smart-contracts/ --000000000000278ffa05e442a563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Discussions on covenants have been prolific and= intense on this mailing list and within the wider Bitcoin technical circle= s, I believe however without succeeding to reach consensus on any new set o= f contracting primitives satisfying the requirements of known covenant-enab= led use-cases. I think that's a fact to deplore as covenants would not = only offer vast extensions of the capabilities of Bitcoin as a system, i.e = enabling new types of multi-party contract protocols. But also empowering B= itcoin on its fundamental value propositions of store of value (e.g by maki= ng vaults more flexible) and payment system (e.g by making realistic channe= l factories/payment pools).

If we retain as a covenant definition, a= spending constraint restricting the transaction to which the spent UTXO ca= n be spent, and enabling to program contracts/protocols at the transaction-= level instead of the script-level, the list of Script primitives proposed d= uring the last years has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1= ], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], P= USHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP [= 9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, = all the listed primitives are at different states of formalization, some al= ready fully fleshed-out in BIPs, other still ideas on whiteboard, yet they = all extend the range of workable multi-party contract protocols.

Ind= eed this range has grown wild. Without aiming to be exhaustive (I'm cer= tainly missing some interesting proposals lost in the abyss of bitcointalk.org), we can mention the following u= se-cases: multi-party stateful contracts [11], congestion trees [12], payme= nt pools [13], "eltoo" layered commitments [14], programmable vau= lts [15], multi-events contracts [16], blockchain-as-oracle bets [17], spac= echains [18], trustless collateral lending [19], ...

Minding all tho= se facts, I would say the task of technical evaluation of any covenant prop= osal sounds at least two fold. There is first reasoning about the enabled p= rotocols on a range of criterias such as scalability, efficiency, simplicit= y, extensibility, robustness, data confidentiality, etc. Asking questions l= ike what are the interactions between layers, if any ? Or how robust is the= protocol, not just interactivity failure between =C2=A0participant nodes b= ut in the face of mempools spikes or internet disruption ? Or if the perfor= mance is still acceptable on shared resources like blockspace or routing ta= bles if everyone is using this protocol ? Or if the protocol minimizes regu= latory attack surface or centralization vectors ?

Though once this s= tep 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 t= rade-offs, but also if there are no functionality overlap or hard constrain= ts on the use-cases design themselves or evolvability w.rt future Script ex= tensions or generalization of the opcode operations.

Moreover, if yo= u would like your evaluation of a covenant proposal to be complete, I don&#= 39;t believe you can squeeze the implications with the mempool rules and co= mbination with any consistent fee-bumping strategy. To say things politely,= those areas have been a quagmire of vulnerabilities, attacks and defects f= or second-layers Bitcoin protocols during the last years [20].

Consi= dering the abundant problem-space offered by covenants, I believe there is = a reasonable groundwork to pursue in building the use-cases understanding (= e.g prototype, pseudo-specification, documentation, ...) and building conse= nsus on the framework of criterias on which to evaluate them [21]. It might= raise a really high bar for any covenant proposal compared to previous sof= tforks, however I think it would adequately reflect the growth in Bitcoin c= omplexity and funds at stakes during the last years.

Moving towards = this outcome, I would like to propose a new covenant open specification pro= cess, in the same spirit as we have with the BOLTs or dlcspecs. We would ha= ve regular meetings (biweekly/monthly ?), an open agenda where topics of di= scussion can be pinned in advance and documentation artifacts would be buil= t with time driven by consensus (e.g 1st phase could be to collect, pseudo-= specify and find champion(s) for known use-cases ?) and no timeframe. Start= ing date could be September / October / November (later, 2023 ?), giving ti= me for anyone interested in such a covenant process to allocate development= and contribution bandwidth in function of their involvement interest.
=
Learning from the good but specially from the bad with setting up the L= 2 onchain support meetings last year, I think it would be better to keep th= e agenda open, loose and free as much we can in a "burn-the-roadmap&qu= ot; spirit, avoiding to create a sense of commitment or perceived signaling= in the process participants towards any covenant solution. I would guess t= hings to be experimental and evolutionary and folks to spend the first meet= ings actually to express what they would like the covenant process to be ab= out (and yes that means if you're a domain expert and you find the pace= of things too slow sometimes, you have to learn to handle your own frustra= tion...).

In a "decentralize-everything" fashion, I believ= e it would be good to have rotating meeting chairs and multiple covenant do= cumentation archivists. I'm super happy to spend the time and energy bo= otstrapping well such covenant process effort, though as it's Bitcoin l= earn to decentralize yourself.

I'm really curious what the outco= me of such a covenant process would look like. We might end up concluding t= hat complex covenants are too unsafe by enabling sophisticated MEV-attacks = against LN [22]. Or even if there is an emergent technical consensus, it do= esn't mean there is a real market interest for such covenant solutions.= That said, I'm not sure if it's really a subject of concern when y= ou're reasoning as a scientist/engineer and you value technical stateme= nts in terms of accuracy, systematic relevance and intrinsic interest.
<= br>Overall, my motivation to kick-start such a process stays in the fact th= at covenants are required building blocks to enable scalable payments pools= design like CoinPool. I believe payments pools are a) cool and b) a good s= hot at scaling Bitcoin as a payment system once we have reached scalability= limits of Lightning, still under the same security model for users. Howeve= r, as a community we might sense it's not the good timing for a covenan= t process. I'm really fine with that outcome as there are still holes t= o patch in LN to keep me busy enough for the coming years.

Zooming o= ut, I believe with any discussion about covenants or other soft forks, the = hard part isn't about coming up with the best technical solution to a s= et of problems but in the iterative process where all voices are listened t= o reach (or not) consensus on what is actually meant by "best" an= d if the problems are accurate. The real physics of Bitcoin is the physics = of people. It's a work of patience.

Anyways, eager to collect fe= edbacks on what the ideal covenant specification process looks like. As usu= al, all opinions and mistakes are my own.

Cheers,
Antoine

= [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[= 1] https= ://bitcoinops.org/en/topics/op_checksigfromstack/
[2] https://github= .com/bitcoin/bips/blob/master/bip-0119.mediawiki
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September= /019419.html
[4] https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2022-January/019813.html
[5] https://github.com= /jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
[6] https://medium.= com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
[7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Febru= ary/019926.html
[8] https://lists.linuxfoundation= .org/pipermail/bitcoin-dev/2018-February/015700.html
[9] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/01924= 3.html
[10] https://github.com/bitcoin/bips/blob/master/bip-0116.med= iawiki
[11] https://lists.linuxfoundation.org/pipe= rmail/bitcoin-dev/2022-January/019808.html
[12] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawi= ki#Congestion_Controlled_Transactions
[13] https://li= sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
= [14] https://lists.linuxfoundation.org/pipermail/lightn= ing-dev/2020-January/002448.html
[15] http://fc17.ifca.ai/bitcoin/papers/b= itcoin17-final28.pdf
[16] https://github.com/ariard/talk-s= lides/blob/master/advanced-contracts.pdf
[17] https://blog.bitmex.com/taproot-you-betch= a/
[18] https://gist.github.com/RubenSomsen/c9f0a9= 2493e06b0e29acced61ca9f49a#spacechains
[19] https://gist.gith= ub.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
[20] https://github.com/jamesob/mempool= .work
[21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806<= /a>
[22] https://blog.bitmex.com/txwithhold-smart-contracts/
--000000000000278ffa05e442a563--