From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3C359C002D for ; Sat, 10 Sep 2022 00:11:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0FD0860F4C for ; Sat, 10 Sep 2022 00:11:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0FD0860F4C Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JWO51+1P 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9NdirBzj8FK for ; Sat, 10 Sep 2022 00:11:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B2A7260F4B Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by smtp3.osuosl.org (Postfix) with ESMTPS id B2A7260F4B for ; Sat, 10 Sep 2022 00:11:13 +0000 (UTC) Received: by mail-io1-xd2c.google.com with SMTP id q83so636946iod.7 for ; Fri, 09 Sep 2022 17:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=8qe/9d+q0L9mteL/LCG3rZ+yGiyCfDYbZ2vU3vBkwEc=; b=JWO51+1PIUI82n8WEdKhKYttal0EMik4sHRg1BNWXnNW8yzQZhzMGzatpFtLsZQLWI 4k8TOS9xahcJ5Bvj2JdIfwCEtxM7JfF0Sm8xdFkOMmgXMXVkiagr0SejxksA1EuFBQkp KBcqgAKU/Lpf7jrewVollq/NB/eTs9Eh12KMpTCEuPMhyPavUwyljxMQvuLn1uxRrS0G 3rK1CLUnDErY9HugP2L5JXpQHfK6kAyqCzZwRhmQA1EvUzwaRruoHj+L+8ZBD0wy4I/o lBhz8s1/3hWkgngXMsXEEWCeni199gWhOVPuBAqTqyHc8cDDa98xvZvWHYgLtFhtllCB 6ljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=8qe/9d+q0L9mteL/LCG3rZ+yGiyCfDYbZ2vU3vBkwEc=; b=Bo6gz2KGbXuyJniQVIAyFJZr1g2kcTHt+SNJ/O3dutOV1K6J8pPcZi/6xKDeJwxiJT rwObRp3JElcth7942C70YKDs76+bKFadseHA4yoXWcfqQ/1aUbkvYu9d1hBXEBTYUkl9 2uM8MZRUc3hDXTTvuGrRBwGGyb8wTIfPYGOiFBsvAdyFlZjHYGSJjy0aFYyiv4LMyfj3 LGa+6hmDOqLTMorRkcHoH+1OEDFHSGMZKYYRdnE9zemTw3UzqKmt/VGDTzFeBb77YPQE m5+sX/gn+jFFd1A0i6RG7lOsE9CjRo76vIDpns9PiljqsF0HttIIFCuBiyj1yZxsF7dQ Odfw== X-Gm-Message-State: ACgBeo3RCjYwoLlTA/CjR977t/yhEXw4XlBVCwhXT1ABj93HnnPNQtE7 Gq5I6H47mq5nnbZ3pF1b3opCKl13/sWiroWLPYT56hZgDGxXYw== X-Google-Smtp-Source: AA6agR7pqNrnOdmRZ/VIbVZb9OhJyJnRgNqkLbXNvuXtyjV0mVYEMI6rmyN6MfFbdwr1/Pmp953Qbqgd8LG0bnAqWqA= X-Received: by 2002:a05:6638:2186:b0:349:c510:6201 with SMTP id s6-20020a056638218600b00349c5106201mr8285420jaj.43.1662768666805; Fri, 09 Sep 2022 17:11:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 9 Sep 2022 20:10:55 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ba88f505e8477f2f" X-Mailman-Approved-At: Sat, 10 Sep 2022 00:45:36 +0000 Subject: Re: [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: Sat, 10 Sep 2022 00:11:17 -0000 --000000000000ba88f505e8477f2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Following up on my July's mail proposing to setup a new community process dedicated to covenant R&D, after aggregating all the feedbacks received online/offline, I've started a repository to collect the use-cases and known design constraints: https://github.com/ariard/bitcoin-contracting-primitives-wg One notable change, the proposed process has been renamed to "Bitcoin Contracting Primitives WG", as covenants sound for few folks to be inaccurate in terms of scope to designate the whole range of techniques to enable/empower contracting applications. So far, I've documented the extension of the vault and payment pools use-cases. Use-case analysis is following somehow inspired by the reasoning framework as laid out by RFC 3426 [0]. This is a first shot and all current descriptions should only be taken as a "best-effort" for now. More use-cases descriptions coming soon. Hopefully we'll have a set of "champions" by use-case emerging with time. There is another ongoing effort to document the primitives themselves: https://github.com/bitcoinops/bitcoinops.github.io/pull/806 About the starting point for regular meetings, I think the good timing is somewhere in November, after the upcoming cycle of Bitcoin conferences, as I guess a good chunk of folks will attend them. Defining a communication channel is still an open question: IRC, Slack, Discord, Discourse, ... As discussed before, softfork activation discussions will be considered as off-topic and discouraged. This is first and foremost a long-term R&D effort. Contributors, reviewers and co-maintainers to the repository are welcome. All content is licensed under Creative Commons 4.0, though can be relicensed to another thing if it suits more (like all Bitcoin devs I'm only part-time lawyer). Still open to more feedbacks on what the ideal Bitcoin covenants/contracting primitives community process would looks like. Cheers, Antoine [0] https://www.rfc-editor.org/rfc/rfc3426.html Le mer. 20 juil. 2022 =C3=A0 16:42, Antoine Riard = a =C3=A9crit : > 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-case= s. > 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 i= ts > fundamental value propositions of store of value (e.g by making vaults mo= re > 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 year= s > 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_GROU= P > [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, a= ll > 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], "elto= o" > layered commitments [14], programmable vaults [15], multi-events contract= s > [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 a= ny > ? 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 resource= s > 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 generalizatio= n > 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 mempo= ol > 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, ...) a= nd > building consensus on the framework of criterias on which to evaluate the= m > [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 bandwidt= h > 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 th= e > 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 hav= e > 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 a= n > 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 tha= t > 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 fo= r > 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 soluti= on > 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/01= 9419.html > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= 13.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/019= 926.html > [8] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015= 700.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/0198= 08.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/00= 2448.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#spac= echains > [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/ > --000000000000ba88f505e8477f2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Following up on my July's mail proposin= g to setup a new community process dedicated to covenant R&D, after agg= regating all the feedbacks received online/offline, I've started a repo= sitory to collect the use-cases and known design constraints:

https://g= ithub.com/ariard/bitcoin-contracting-primitives-wg

One notable c= hange, the proposed process has been renamed to "Bitcoin Contracting P= rimitives WG", as covenants sound for few folks to be inaccurate in te= rms of scope to designate the whole range of techniques to enable/empower c= ontracting applications.

So far, I've documented the extension o= f the vault and payment pools use-cases. Use-case analysis is following som= ehow inspired by the reasoning framework as laid out by RFC 3426 [0]. This = is a first shot and all current descriptions should only be taken as a &quo= t;best-effort" for now. More use-cases descriptions coming soon. Hopef= ully we'll have a set of "champions" by use-case emerging wit= h time.

There is another ongoing effort to document the primitives t= hemselves:

https://github.com/bitcoinops/bitcoinops.github.io/pull/806=

About the starting point for regular meetings, I think the good= timing is somewhere in November, after the upcoming cycle of Bitcoin confe= rences, as I guess a good chunk of folks will attend them.

Defining = a communication channel is still an open question: IRC, Slack, Discord, Dis= course, ...

As discussed before, softfork activation discussions wil= l be considered as off-topic and discouraged. This is first and foremost a = long-term R&D effort.

Contributors, reviewers and co-maintainers= to the repository are welcome. All content is licensed under Creative Comm= ons 4.0, though can be relicensed to another thing if it suits more (like a= ll Bitcoin devs I'm only part-time lawyer).

Still open to more f= eedbacks on what the ideal Bitcoin covenants/contracting primitives communi= ty process would looks like.

Cheers,
Antoine

[0] https://www.rfc-editor.org= /rfc/rfc3426.html

Le=C2=A0mer. 20 juil. 2022 =C3=A0=C2=A016:42, Anto= ine Riard <antoine.riard@gmai= l.com> a =C3=A9crit=C2=A0:
Hi,

Discussions on covenants have= been prolific and intense on this mailing list and within the wider Bitcoi= n technical circles, I believe however without succeeding to reach consensu= s on any new set of contracting primitives satisfying the requirements of k= nown covenant-enabled use-cases. I think that's a fact to deplore as co= venants 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 makin= g realistic channel factories/payment pools).

If we retain as a cove= nant definition, a spending constraint restricting the transaction to which= the spent UTXO can be spent, and enabling to program contracts/protocols a= t the transaction-level instead of the script-level, the list of Script pri= mitives proposed during the last years has grown large : ANYPREVOUT [0], CH= ECKSIGFROMSTACK [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 rem= ember. Of course, all the listed primitives are at different states of form= alization, some already fully fleshed-out in BIPs, other still ideas on whi= teboard, yet they all extend the range of workable multi-party contract pro= tocols.

Indeed this range has grown wild. Without aiming to be exhau= stive (I'm certainly missing some interesting proposals lost in the aby= ss of bitcointalk.org<= /a>), we can mention the following use-cases: multi-party stateful contract= s [11], congestion trees [12], payment pools [13], "eltoo" layere= d commitments [14], programmable vaults [15], multi-events contracts [16], = blockchain-as-oracle bets [17], spacechains [18], trustless collateral lend= ing [19], ...

Minding all those facts, I would say the task of techn= ical evaluation of any covenant proposal sounds at least two fold. There is= first reasoning about the enabled protocols on a range of criterias such a= s scalability, efficiency, simplicity, extensibility, robustness, data conf= identiality, etc. Asking questions like what are the interactions between l= ayers, if any ? Or how robust is the protocol, not just interactivity failu= re between =C2=A0participant nodes but in the face of mempools spikes or in= ternet disruption ? Or if the performance is still acceptable on shared res= ources 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 re= asoning 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 fun= ctionality overlap or hard constraints on the use-cases design themselves o= r evolvability w.rt future Script extensions or generalization of the opcod= e operations.

Moreover, if you would like your evaluation of a coven= ant proposal to be complete, I don't believe you can squeeze the implic= ations with the mempool rules and combination with any consistent fee-bumpi= ng strategy. To say things politely, those areas have been a quagmire of vu= lnerabilities, attacks and defects for second-layers Bitcoin protocols duri= ng the last years [20].

Considering the abundant problem-space offer= ed by covenants, I believe there is a reasonable groundwork to pursue in bu= ilding the use-cases understanding (e.g prototype, pseudo-specification, do= cumentation, ...) and building consensus on the framework of criterias on w= hich to evaluate them [21]. It might raise a really high bar for any covena= nt proposal compared to previous softforks, however I think it would adequa= tely reflect the growth in Bitcoin complexity and funds at stakes during th= e last years.

Moving towards this outcome, I would like to propose a= new covenant open specification process, in the same spirit as we have wit= h the BOLTs or dlcspecs. We would have regular meetings (biweekly/monthly ?= ), an open agenda where topics of discussion can be pinned in advance and d= ocumentation artifacts would be built with time driven by consensus (e.g 1s= t 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 cove= nant process to allocate development and contribution bandwidth in function= of their involvement interest.

Learning from the good but speciall= y 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 w= e can in a "burn-the-roadmap" spirit, avoiding to create a sense = of commitment or perceived signaling in the process participants towards an= y covenant solution. I would guess things to be experimental and evolutiona= ry and folks to spend the first meetings actually to express what they woul= d 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 "decentraliz= e-everything" fashion, I believe it would be good to have rotating mee= ting chairs and multiple covenant documentation archivists. I'm super h= appy 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 loo= k 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 i= nterest 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/engi= neer and you value technical statements in terms of accuracy, systematic re= levance and intrinsic interest.

Overall, my motivation to kick-start= such a process stays in the fact that covenants are required building bloc= ks to enable scalable payments pools design like CoinPool. I believe paymen= ts pools are a) cool and b) a good shot at scaling Bitcoin as a payment sys= tem once we have reached scalability limits of Lightning, still under the s= ame 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 tha= t outcome as there are still holes to patch in LN to keep me busy enough fo= r the coming years.

Zooming out, I believe with any discussion about= covenants or other soft forks, the hard part isn't about coming up wit= h the best technical solution to a set of problems but in the iterative pro= cess where all voices are listened to reach (or not) consensus on what is a= ctually meant by "best" and if the problems are accurate. The rea= l physics of Bitcoin is the physics of people. It's a work of patience.=

Anyways, eager to collect feedbacks on what the ideal covenant spec= ification process looks like. As usual, all opinions and mistakes are my ow= n.

Cheers,
Antoine

[0] https://github.co= m/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/pip= ermail/bitcoin-dev/2021-September/019419.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= 022-January/019813.html
[5] https://github.com/jl201= 2/bips/blob/vault/bip-0ZZZ.mediawiki
[6] htt= ps://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
[7= ] https://lists.linuxfoundation.org/pi= permail/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://lis= ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html[12] https://github.= com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Trans= actions
[13] https://lists.linuxfou= ndation.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-cont= racts.pdf
[17] https://blog.bitmex.com/taproot-you-betcha/
[18= ] https://gist.github.com/RubenSomsen/c= 9f0a92493e06b0e29acced61ca9f49a#spacechains
[19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef<= /a>
[20] https://github.com/jamesob/mempool.work
[21] h= ttps://github.com/bitcoinops/bitcoinops.github.io/pull/806
[22] https://blog.bitmex.com/txwithhold-smart-contracts/
--000000000000ba88f505e8477f2f--