From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E2AFAC002D for ; Sun, 1 May 2022 23:03:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C168140275 for ; Sun, 1 May 2022 23:03:14 +0000 (UTC) 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 Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxtXFu8FuHrl for ; Sun, 1 May 2022 23:03:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by smtp2.osuosl.org (Postfix) with ESMTPS id B427E40260 for ; Sun, 1 May 2022 23:03:12 +0000 (UTC) Received: by mail-pf1-x42a.google.com with SMTP id j6so11044008pfe.13 for ; Sun, 01 May 2022 16:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6BHLw914Dp6Yk0C++lw4Nvc3RQglGAyQ/Wh+2kgPpYI=; b=FlJ3ghM/5PPKZ7+fhIe18JDhdASkMSEGwEQS59/7FpkgQ/Gq9Xg92+kxtyjWyPS27j jbx/lv+zXolCMEI/q9uadtKN47KQmxDOsO4/iHimVolR75P47NR/z6A+komei+97NWXI f2ty/xn8vyFz2M1puA1lUybFCW25ggA0icX9o8gg08RKGoZYyOZCbWX5G0eK8wQ+Mel9 QAy6AfRWHHlNySVMf7FHwzYwDC+NB3eDxGV7CeuhpxpNmUef5pIXqMxY2TR8ip1idbQS 9tjJHD+r8sXyc6VteyizuCfYNP7nlGSpxo7pxAvWKlWSNn8lQ8fEyem0R2GtD99QQEzd qGBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6BHLw914Dp6Yk0C++lw4Nvc3RQglGAyQ/Wh+2kgPpYI=; b=b4zDt5JY0VBUTex/C+bS3nJwAfiG7AV26yDbsU9rGzzQuY97ZeaqSG6YC3QGhFURVl /snpnW44JDC+DPK6V+PCTFGUW1vxBJehZfTMwuWXiQrX/JBkccGih0oxiacFFNnAozB8 GCMcjVwQgnIiN3BaKpgVM2Scdn5IZQ5MmqoPPlO321FKoVqp+gM0ynolBgPk7VW6Qcnw QQLGz/1G930Bh1N8BnL8ldXhzk55HtOv98vNMDBggkMuY2knyZtrUWVzxKcY/+rBYcSv pLS8nqIrqjQ3BDAn55ihmEGPXBElDcUsDbyL+ijomSYIiEw0IYF0K4oy4dkX1WQqW5CZ fijw== X-Gm-Message-State: AOAM533Ek05CuIIv5FlduX4hIbffEMMzijN1v/s8LtvdKvQYKfQCQrVU q8ytuSUSzi/0xxFjzRC1BcTkpv4uyTbtUEhybqitSlTR X-Google-Smtp-Source: ABdhPJz+CgNgXWTd2yt4Ax7V+TzeojXYsdgkJjLzHk0SIzu9OTZAll9G7jqfJXVGnAIxKlvfDWOIxt06RzdgxDe0Nzg= X-Received: by 2002:aa7:8215:0:b0:4f7:125a:c88c with SMTP id k21-20020aa78215000000b004f7125ac88cmr8741937pfi.70.1651446191968; Sun, 01 May 2022 16:03:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Sun, 1 May 2022 18:02:55 -0500 Message-ID: To: alicexbt , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a3566d05ddfb477e" X-Mailman-Approved-At: Mon, 02 May 2022 08:57:23 +0000 Subject: Re: [bitcoin-dev] Multiple ways to do bitcoin 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: Sun, 01 May 2022 23:03:15 -0000 --000000000000a3566d05ddfb477e Content-Type: text/plain; charset="UTF-8" I've been thinking about writing something about covenant proposals from the viewpoint of wallet vaults specifically (mostly because that's the use case I care most about). CTV is basically the minimal covenant opcode you can do that doesn't have malleability. Everything else either introduces malleability, infinite recursion, or has interactions with other proposed opcodes that could introduce potentially undesirable effects like those. TXHASH+CSFS seems like on its own might enable pretty much identical capabilities to CTV (including no malleability). But it can also do other things (mostly because CSFS can do other things), which isn't necessarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in terms of wallet vaults seems to provide no benefits over CTV as far as I can imagine. It seems pretty clear that anything involving OP_CAT is out for the time being. There are so many things it can enable that it seems most people aren't comfortable adding it at the moment. APO wallet vaults seem rather hacky, inefficient, and limited. Certainly not easy to reason about. But this is somewhat a function of my limited understanding of them. Its not clear to me if anyone is actually suggesting that we should use APO for covenants, but it doesn't feel like the right approach. TLUV + IN_OUT_AMOUNT can do infinitely recursive covenants. IN_OUT_AMOUNT wasn't very clearly specified that I know of, but its not a very robust way of ensuring the correct amount goes where you want. If TLUV requires a single input and a single output, IN_OUT_AMOUNT makes sense because you can simply do opcode math to determine if the output is receiving enough coins (and not eg being all lost as fees). Maybe it could be extended to allow multiple outputs, but extending it to allow for multiple inputs would be difficult and you'd probably want a completely different mechanism for that. If you're doing any math the script itself around amounts and fees, this doesn't work well in any scenario where multiple inputs might send to the same address, or be combined into the same output, since each input's script can't interact. But since TLUV at its most basic should be able to say "remove the only tapleaf in this tree and replace it with this other tap tree", it should be able to do pretty arbitrary covenants. It ideally should be paired up with something that has better control over how input amounts flow to outputs than IN_OUT_AMOUNT allows (see the design considerations here ). TLUV is built for evictions, but it seems its likely not really very good at that, as Zman mentioned in his post about OP_EVICT (which is a covenant opcode that can't be used for wallet vaults, tho perhaps its characteristics can be used in a kind of TLUV2 opcode that does evictions better, but also can add tapleaves). OP_CHECKOUTPUTVERIFY is another interesting one. Also has a form that allows recursive covenants. It also has similar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input transactions. It has the half-spend problem if two outputs are combined that specify the same output index and script pattern. It also seems like a rather expensive opcode to use beyond very simple covenants, since the scripts basically has to be duplicated in the transaction specifying the covenant and then again when the subsequent transaction is spent. Its not very taproot friendly either: would you have to specify the entire taproot script tree? Any similar opcode that requires specifying the exact script(s) fundamentally can't take advantage taproot's ability to keep scripts private until that spend path is actually used. As far as I can tell, few of these other covenant opcodes have even been concretely specified, let alone analyzed enough to know whether they're worth pursuing. It seems like all but CTV (potentially TXHASH+CSFS) have significant flaws and would need reworking in order to fix them. I guess in short, I agree with you. Over these other ideas that have gotten significant attention, none really seem to be of high enough quality to be put into bitcoin in their current state. On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > CTV and other covenant proposals, tradeoffs, and overlapping features are > among the topics being explored recently. I had some views and questions on > this subject.: > > a) Does bitcoin already have opcodes with overlapping features? Yes > > b) Can we have multiple ways with some overlapping features to do bitcoin > covenants with some tradeoffs? Yes > _ > c) What are these tradeoffs if we compare CTV, APO, TLUV and TXHASH+CSFS? > > I am sure about a) because it was already answered in CTV chat by Jeremy > and sheshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and > OP_ADD > > Not sure if we have "consensus" on b) but I don't see anything wrong with > it. > > For c) I would prefer CTV because: > > - Simpler > - Blockspace effient > - Can be used even without taproot > > Covering bare script, as in segwit v0, is necessary. Exposing a pubkey in > case of an EC break will be a disaster, and vaults imply very long lived > storage. Root CA offline certificates can often have shelf life measured in > decades. However, NSA has issued warnings, NIST has issued guidelines, and > executive order to prepare for the quantum shift. As a result, forcing > everyone into a quantum-unsafe position is unsustainable. > > Other developers might use a different way to do bitcoin covenant for > other reasons. Example: Russel O'Connor would prefer general OP_TXHASH > design > > /dev/fd0 > > Sent with ProtonMail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a3566d05ddfb477e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been thinking about writing something about coven= ant proposals from the viewpoint of wallet vaults specifically (mostly beca= use that's the use case I care most about).=C2=A0

CT= V is basically the minimal covenant opcode you can do that doesn't have= malleability. Everything else either introduces malleability, infinite rec= ursion, or has interactions=C2=A0with other proposed opcodes that could int= roduce potentially undesirable effects like those.=C2=A0

TXHASH+CSFS seems like on its own might enable pretty much identical= =C2=A0capabilities to CTV (including no malleability). But it can also do o= ther things (mostly because CSFS can do other things), which isn't nece= ssarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in term= s of wallet vaults seems to provide no benefits over CTV as far as I can im= agine.=C2=A0

It seems pretty clear that anything i= nvolving OP_CAT is out for the time being. There are so many things it can = enable that it seems most people aren't comfortable adding=C2=A0it at= =C2=A0 the moment.=C2=A0

APO wallet vaults seem ra= ther hacky, inefficient, and limited. Certainly not easy to reason about. B= ut this is somewhat a function of my limited understanding of them. Its not= clear to me if anyone is actually suggesting that we should use APO for co= venants, but it doesn't=C2=A0feel like the right approach.
TLUV +=C2=A0IN_OUT_AMOUNT can do infinitely recursive covenants.=C2=A0IN_OUT_AMOUNT wasn't ve= ry clearly specified that I know of, but its not a very robust way of ensur= ing the correct amount goes where you want. If TLUV requires a single input= and a single output, IN_OUT_AMOUNT makes sense because you can simply do opcode math to = determine if the output is receiving enough coins (and not eg being all los= t as fees). Maybe it could be extended to allow multiple outputs, but exten= ding it to allow for multiple inputs would be difficult and you'd proba= bly want a completely different mechanism for that. If you're doing any= math the script itself around amounts and fees, this doesn't work well= in any scenario where multiple inputs might send to the same address, or b= e combined into the same output, since each input's script can't in= teract.

But since TLUV at its most basic should be able to say "remove t= he only tapleaf in this tree and replace it with this other tap tree",= it should be able to do pretty arbitrary covenants. It ideally should be p= aired up with something that has better control over how input amounts flow= to outputs than IN_OUT_AMOUNT allows (see the design considerations here).

=
TLUV is built for evictions, but it seems its likely not really very g= ood at that, as Zman mentioned in his = post about OP_EVICT (which is a covenant opcode that can't be used = for wallet vaults,=C2=A0tho perhaps its characteristics can be used in a ki= nd of TLUV2 opcode that does evictions better, but also can add tapleaves).=

OP_CHECKOUTPUTVERIFY=C2=A0is another interes= ting one. Also has a form that allows recursive covenants. It also has simi= lar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input transactions. It= has the half-spend problem if two outputs are combined that specify the sa= me output index and script pattern. It also seems like a rather expensive o= pcode to use beyond very simple covenants, since the scripts basically has = to be duplicated in the transaction specifying the covenant and then again = when the subsequent transaction is spent. Its not very taproot friendly eit= her: would you have to specify the entire taproot script tree? Any similar = opcode that requires specifying the exact script(s) fundamentally can't= take advantage taproot's=C2=A0ability to keep scripts private until th= at spend path is actually used.

As far as I can te= ll, few of these other covenant opcodes have even been concretely specified= , let alone analyzed enough to know whether they're worth pursuing. It = seems like all but CTV (potentially TXHASH+CSFS) have significant flaws and= would need reworking in order to fix them.=C2=A0

= I guess in short, I agree with you. Over these other ideas that have gotten= significant attention, none really seem to be of high enough quality to be= put into bitcoin in their current state.=C2=A0



On Thu, Apr 28, 2022 at 3:47 AM alicexbt via bitcoin= -dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
CTV and other covenant proposals, tradeoffs, and o= verlapping features are among the topics being explored recently. I had som= e views and questions on this subject.:

a) = Does bitcoin already have opcodes with overlapping features? Yes

b) Can we have multiple ways with some overlapp= ing features to do bitcoin covenants with some tradeoffs? Yes
<= div>_
c) What are these tradeoffs if we compar= e CTV, APO, TLUV and TXHASH+CSFS?

I a= m sure about a) because it was already answered in CTV chat by Jeremy and s= heshek. Example: CHECKSIG and CHECKSIGADD is redundant with OP_IF and OP_AD= D

Not sure if we have "consensus= " on b) but I don't see anything wrong with it.
<= br>
For c) I would prefer CTV because:
- Simpler
- Blockspace effient
- Can be used even without taproot
Covering bare script, as in segwit v0, is necessary. Expo= sing a pubkey in case of an EC break will be a disaster, and vaults imply v= ery long lived storage. Root CA offline certificates can often have shelf l= ife measured in decades. However, NSA has issued warnings, NIST has issued = guidelines, and executive order to prepare for the quantum shift. As a resu= lt, forcing everyone into a quantum-unsafe position is unsustainable.

Other developers might use a different way= to do bitcoin covenant for other reasons. Example: Russel O'Connor wou= ld prefer general OP_TXHASH design

/dev/fd0

Sent with ProtonMail secure email.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a3566d05ddfb477e--