Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7F515C002D for ; Sat, 30 Apr 2022 11:15:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6133C40103 for ; Sat, 30 Apr 2022 11:15:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.975, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 z3HU44pQ_SGf for ; Sat, 30 Apr 2022 11:15:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by smtp2.osuosl.org (Postfix) with ESMTPS id 45E1B40022 for ; Sat, 30 Apr 2022 11:15:36 +0000 (UTC) Received: by mail-yb1-xb32.google.com with SMTP id v59so18565987ybi.12 for ; Sat, 30 Apr 2022 04:15:36 -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 :cc; bh=g6qLXtlg5rfxbhrJ05ClUs+4DTst0wkJrwT03O7wyN8=; b=hn47i9dYSlZc/xIMxCASuX6XRmNgZ9ERxPRiocvXNcmH82X8nklUlWpVT7Sm1GV9o3 b71kSk8kKQmK7pXn/DFb7j8a2q5T/QkC4YngK84x4JPj8ujUeQ/OUoxyxN4SF53/R0cQ AEOmcGw4nvdmRu6vFOZ8bezRYVIQ4YOEj3RyQt+gYRTXoofgkZqGXiS7pE9zAAuRhG9V vmqbSsLTW6bcO68KX7VHwwlSn9lBxwGmV6fjoMJduemORZnLy+83UTbjxYBdZpOVbou5 rJYLd53q16WWN/HuXowawBxbbMikNchaUGMXAkVFzPG0Soxz4JaJay4P92UJ3QS2joXe DMLA== 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:cc; bh=g6qLXtlg5rfxbhrJ05ClUs+4DTst0wkJrwT03O7wyN8=; b=HzAXWHGWlYx/ZDCYC58f8njYT9TjBlEkseEtTjXtVlA3PE/1/1SToy1k/YIzRYkeV9 SxYaCEC5xcpXmCVEBpAJKGgg+mSqdOVIuDS3o1ysOAPa4bf/PsC5pJCRc8rL6D7ywZES +32m0Aqe7EfxUsgNvRCGKZJyOKPVMr+L8UZ2p8epkCL2jaf93a+CJwQ+qMilk4m92Zv8 VIwTJeibgD6iPOlXUCXMBrCqGwYKmcdfL4t2h8uOpnT2MXjsCV+EYZe/DseYgQTjV39X o2Rdx4+jbkYxxfYIUczRNXYKLph3ShNmJVj4Yx3HG79BrpkWMEgL4AWZXUUDMM2fxCCT iOHw== X-Gm-Message-State: AOAM533KXRkFXUL36Le//Q+gTH0+phyYqtmNuJK5dTRyuF9LTmrRhFyG JOolLnKV6NdeV7TEKI5zErGmUclIkvhM2/sz4Co= X-Google-Smtp-Source: ABdhPJya7wyXmqnqBm80sY82tmpA7yKPJZpPh5D23Z2p6+/XZKoBmoG/mKBrrYD+L+xG4L0cbYGPljQe0H74shnnOtY= X-Received: by 2002:a05:6902:708:b0:649:3c01:51d9 with SMTP id k8-20020a056902070800b006493c0151d9mr3757150ybt.160.1651317334914; Sat, 30 Apr 2022 04:15:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Sat, 30 Apr 2022 07:15:25 -0400 Message-ID: To: Nadav Ivgi , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000028b8d705dddd473d" Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV 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, 30 Apr 2022 11:15:38 -0000 --00000000000028b8d705dddd473d Content-Type: text/plain; charset="UTF-8" The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't commit to amount, so I'd also assume it not be re-added or at least be able to be opened out. On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi darosior, > > It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY > behaviour and without covering the spent input index) has some interesting > uses for cases where the covenant only needs to restrict a single output > (so useful for e.g. vaults or spacechains, but not for batch channels or > congestion control). > > For example in the vault use-case, it makes it possible to bump fees on > the unvault tx by adding more inputs and a change output, as well as > unvault multiple vaulted outputs in a single transaction. > > For spacechains, it makes it possible to add the spaceblock hash OP_RETURN > and pay fees directly in the tx chain, instead of having to use an > additional tx to prepare an output that gets spent in the tx chain (see > the diagram in [0]). > > > via `sha_sequences` and maybe also `sha_amounts` > > CTV does not commit to the input amounts. This has some practical > implications: > > 1. If it is committed, sending an even slightly incorrect amount will make > the covenant-encumbered spend path unusable. > > With CTV, sending a slightly lower amount results in slightly lower fees, > while any extra gets spent/burned on fees. The covenant spend path only > becomes unusable if the amount is too low to cover for the outputs (+relay > fee for it to also be standard). > > 2. The ability to allow for additional inputs with unknown amounts makes > it possible to fee-bump the covenant spending transaction (with whole utxos > and no change). You can have one tapleaf for spending the covenant output > alone, and another one for attaching an extra fee input to it. > > This also makes it possible to resolve the under-payment issue described > in (1), by adding an input that covers the original intended amount. > > So my suggestion would be to either not cover `sha_amounts` in the msg > hash, or to make it optional behind a flag. > > shesek > > [0] https://github.com/fiatjaf/simple-ctv-spacechain > > On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would like to know people's sentiment about doing (a very slightly >> tweaked version of) BIP118 in place of >> (or before doing) BIP119. >> >> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for >> over 6 years. It presents proven and >> implemented usecases, that are demanded and (please someone correct me if >> i'm wrong) more widely accepted than >> CTV's. >> >> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made >> optional [0], can emulate CTV just fine. >> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more >> expensive to use. But we can consider CTV >> an optimization of APO-AS covenants. >> >> CTV advocates have been presenting vaults as the flagship usecase. >> Although as someone who've been trying to >> implement practical vaults for the past 2 years i doubt CTV is necessary >> nor sufficient for this (but still >> useful!), using APO-AS covers it. And it's not a couple dozen more >> virtual bytes that are going to matter for >> a potential vault user. >> >> If after some time all of us who are currently dubious about CTV's stated >> usecases are proven wrong by onchain >> usage of a less efficient construction to achieve the same goal, we could >> roll-out CTV as an optimization. In >> the meantime others will have been able to deploy new applications >> leveraging ANYPREVOUT (Eltoo, blind >> statechains, etc..[1]). >> >> >> Given the interest in, and demand for, both simple covenants and better >> offchain protocols it seems to me that >> BIP118 is a soft fork candidate that could benefit more (if not most of) >> Bitcoin users. >> Actually i'd also be interested in knowing if people would oppose the >> APO-AS part of BIP118, since it enables >> CTV's features, for the same reason they'd oppose BIP119. >> >> >> [0] That is, to not commit to the other inputs of the transaction (via >> `sha_sequences` and maybe also >> `sha_amounts`). Cf >> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message >> . >> >> [1] https://anyprevout.xyz/ "Use Cases" section >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000028b8d705dddd473d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The proposed use case for the ANYSCRIPT part of APOAS exp= licitly doesn't commit to amount, so I'd also assume it not be re-a= dded or at least be able to be opened out.=C2=A0

On Sat, Apr 30, 2022, 4:47 = AM Nadav Ivgi via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi darosior,

It's interesting to n= ote that APOAS|SINGLE (with th= e ANYONECANPAY behaviour and w= ithout covering the spent input index) has some interesting uses for cases = where the covenant only needs to restrict a single output (so useful for e.= g. vaults or spacechains, but not for batch channels or congestion control)= .

For example in the vault use-case, it makes it p= ossible to bump fees on the unvault tx by adding more inputs and a change o= utput, as well as unvault multiple vaulted outputs in a single transaction.=

For spacechains, it makes it possible to add = the spaceblock hash OP_RETURN and pay fees directly in the tx chain, instea= d of having to use an additional tx to prepare an output that gets spent in= the tx chain=C2=A0 (see the diagram in [0]).
> via `sha_sequences` and maybe also `sha_amounts`

CTV does not commit to the input amounts. This has some pr= actical implications:

1. If it is committed, s= ending an even slightly incorrect amount will make the covenant-encumbered = spend path unusable.

With CTV, sending a slightly = lower amount results in slightly lower fees, while any extra gets spent/bur= ned on fees. The covenant spend path only becomes unusable if the amount is= too low to cover for the outputs (+relay fee for it to also be standard).<= br>

2. The ability to allow for additional inputs = with unknown amounts makes it possible to fee-bump the covenant spending tr= ansaction (with whole utxos and no change). You can have one tapleaf for sp= ending the covenant output alone, and another one for attaching an extra fe= e input to it.

This also makes it possible to reso= lve the under-payment issue described in (1), by adding an input that cover= s the original intended amount.

So my suggesti= on would be to either not cover `sha_amounts` in the msg hash, or to make i= t optional behind a flag.

shesek
<= div>

On Fri, Apr 22, 2022 at 2:23 PM darosior via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I w= ould like to know people's sentiment about doing (a very slightly tweak= ed version of) BIP118 in place of
(or before doing) BIP119.

SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for ove= r 6 years. It presents proven and
implemented usecases, that are demanded and (please someone correct me if i= 'm wrong) more widely accepted than
CTV's.

SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is m= ade optional [0], can emulate CTV just fine.
Sure then you can't have bare or Segwit v0 CTV, and it's a bit more= expensive to use. But we can consider CTV
an optimization of APO-AS covenants.

CTV advocates have been presenting vaults as the flagship usecase. Although= as someone who've been trying to
implement practical vaults for the past 2 years i doubt CTV is necessary no= r sufficient for this (but still
useful!), using APO-AS covers it. And it's not a couple dozen more virt= ual bytes that are going to matter for
a potential vault user.

If after some time all of us who are currently dubious about CTV's stat= ed usecases are proven wrong by onchain
usage of a less efficient construction to achieve the same goal, we could r= oll-out CTV as an optimization.=C2=A0 In
the meantime others will have been able to deploy new applications leveragi= ng ANYPREVOUT (Eltoo, blind
statechains, etc..[1]).


Given the interest in, and demand for, both simple covenants and better off= chain protocols it seems to me that
BIP118 is a soft fork candidate that could benefit more (if not most of) Bi= tcoin users.
Actually i'd also be interested in knowing if people would oppose the A= PO-AS part of BIP118, since it enables
CTV's features, for the same reason they'd oppose BIP119.


[0] That is, to not commit to the other inputs of the transaction (via `sha= _sequences` and maybe also
`sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#= signature-message.

[1] https://anyprevout.xyz/ "Use Cases" section
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000028b8d705dddd473d--