[bitcoin-dev] ANYPREVOUT in place of CTV

[bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

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

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[rot13maxi]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

Good morning darosior,

Do you know if there is a working implementation of APO somewhere that people can use to try out some of the proposed usecases? For example, it would be great to see what eltoo would actually look like on an APO signet. Or to see some working code for a vault using covenants in an APO world.

I haven’t seen much in the way of APO implementations recently, but I also haven’t gone looking, so would appreciate any links!

Thanks

On Fri, Apr 22, 2022 at 7:11 AM, 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

[-- Attachment #2: Type: text/html, Size: 3138 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

Hi,

Richard Myers has an implementation of Eltoo using Bitcoin Core's functional test framework: https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py.
He blogged about it, too. https://yakshaver.org/2021/07/26/first.html

He seems to have something similar for covenants, but it's WIP: https://github.com/remyers/bitcoin/blob/covenant-anyprevout/test/functional/feature_apocovenant.py. https://yakshaver.org/2021/11/18/covenants.html.

His APO page looks like a good reference on the topic: https://yakshaver.org/bitcoin/#anyprevout.

------- Original Message -------
Le vendredi 22 avril 2022 à 1:44 PM, rot13maxi <rot13maxi@protonmail.com> a écrit :

> Good morning darosior,
>
> Do you know if there is a working implementation of APO somewhere that people can use to try out some of the proposed usecases? For example, it would be great to see what eltoo would actually look like on an APO signet. Or to see some working code for a vault using covenants in an APO world.
>
> I haven’t seen much in the way of APO implementations recently, but I also haven’t gone looking, so would appreciate any links!
>
> Thanks
>
> On Fri, Apr 22, 2022 at 7:11 AM, 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

[-- Attachment #2: Type: text/html, Size: 4868 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Luke Dashjr]

There's no reason for before/after/in place. We have version bits specifically 
so we can have multiple deployments in parallel.

But none of this ST nonsense, please. That alone is a reason to oppose it.

Luke


On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev 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-me
>ssage.
>
> [1] https://anyprevout.xyz/ "Use Cases" section
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Richard Myers]

Hi darosior,

Thanks for sharing your thoughts on this.

> I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> (or before doing) BIP119.

Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.

> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.

For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?

In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.

I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?

Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.

The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.

  -- Richard

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

>
>
> 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.
>

makes sense that byte-efficiency would be likely less important to vault
users vs lightning noninteractive channel users


>
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>

a smaller code change that seems much less controversial

[-- Attachment #2: Type: text/html, Size: 869 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

Hi Richard,

> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do
compete for scarce reviewer time

Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.


> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there
a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?

I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what
ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are
the number of inputs and the hash of the inputs' sequences [1].
Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can
be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV
completely it should be optional.


Antoine

[0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
[1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
[2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522


------- Original Message -------
Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers <remyers@yakshaver.org> a écrit :


> Hi darosior,
>
> Thanks for sharing your thoughts on this.
>
> > I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> > (or before doing) BIP119.
>
>
> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.
>
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
>
>
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.
>
> I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?
>
> Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.
>
> The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.
>
> -- Richard

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

Just a correction to my previous mail. Sorry for the non-attribution, i didn't recall APO covenants had been discussed in the context of CTV.

> > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what

The comparison was already done by Anthony Towns.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017036.html

Jeremy Rubin already pointed out that it missed committing to the nSequences hash and number of inputs (and optionally scriptSigs).
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html


------- Original Message -------
Le lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :


> Hi Richard,
>
> > Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do
>
> compete for scarce reviewer time
>
> Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose
> SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.
>
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there
>
> a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what
> ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are
> the number of inputs and the hash of the inputs' sequences [1].
> Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can
> be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV
> completely it should be optional.
>
>
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
> [1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> [2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522
>
>
> ------- Original Message -------
> Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers remyers@yakshaver.org a écrit :
>
>
>
> > Hi darosior,
> >
> > Thanks for sharing your thoughts on this.
> >
> > > I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> > > (or before doing) BIP119.
> >
> > Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.
> >
> > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
> >
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
> >
> > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.
> >
> > I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?
> >
> > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.
> >
> > The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.
> >
> > -- Richard
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

darosior via bitcoin-dev wrote:

> 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.

Some potential vault users looking to store funds for long time periods
(say of decades) might have quantumphobia and prefer to avoid Taproot for
that reason.

One of the arguments presented for not using pubkey hashes in Taproot is
that quantumphobic people could choose to continue using non-Taproot
outputs. Making a feature that's targeted for long-term cold-storage vaults
available on Taproot only might be less ideal in that view.

Cheers
shesek

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
>

[-- Attachment #2: Type: text/html, Size: 4201 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this

I would be interested to hear more on this.

Is it not necessary because you can exchange and store pre-signed
transactions instead?

What purpose is it not sufficient for? There are some vault designs out
there that are able to achieve interesting properties with CTV, like James
O'Beirne's simple-ctv-vault:

https://github.com/jamesob/simple-ctv-vault
(the basic design expressed in Minsc:
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)

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
>

[-- Attachment #2: Type: text/html, Size: 4431 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Jeremy Rubin]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:

- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful
generically, because I may want to reuse the internal key in conjunction
with a script path in some circumstances.
- Add an additional sequence field that is specific to a signature with no
other consensus meaning, so APO can be used with absolute timelocks. For
example, this makes it impossible for more than one ratchet to be
aggregated within a single transaction under any circumstance if their
sequences differ (not sure this is a good example, but an example
nonetheless).
- Replace tagged keys for APO with either a Checksig2 or a separate feature
flag that enables or disables APO behavior so that we can have programmatic
control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP
CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a
certain time, perhaps for a pre-approved backup transaction).

Overall, this would make eltoo ratchets look something like this:

<sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN

where checksig2 leaves seq on the stack which can be used to enforce the
ratchet.

and covenants like:

<sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY







On Fri, Apr 22, 2022 at 4:23 AM 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
>

[-- Attachment #2: Type: text/html, Size: 7024 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

Here's a summary of the trade-offs I see for using APO as a CTV alternative:

1. The resulting txids are not stable.

CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).

This property could be important for some of the proposed CTV use-cases,
like channel factories.

2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])

3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).

4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).

5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.

If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].

Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).

This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.

shesek

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128



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
>

[-- Attachment #2: Type: text/html, Size: 5964 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

[-- Attachment #1: Type: text/plain, Size: 6851 bytes --]

Hi Shesek,

> 1. The resulting txids are not stable.

This is *literally* what the post you are replying to is proposing to solve.

> This property could be important for some of the proposed CTV use-cases, like channel factories.

Hmm? You can't have channel factories without Eltoo. (Well, you can in theory but good luck.)
Maybe you are refering to non-interactive channel creation? The case for stable txids is less strong if wehave APO (and therefore Eltoo). [0]

> 2. APO will only be available on Taproot, which some people might prefer to avoid for long-term multi-decade vault storage due to QC concerns. (also see my previous post on this thread [0])

This has been addressed over and over and over again. If a QC is able overnight to spend a large fraction of
the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant (that would eventually become
vulnerable when trying to use it) are worthless.[1]

Sorry for being sarcastic, but at this point it's not fair to use quantum-computer FUD to justify theactivation of CTV over APO, or encourage the use of legacy transactions over Taproot ones.

> 3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 in the case of a single CTV branch, for the taproot control block. with more branches CTV-in-taproot eventually becomes preferable).

Again, this is what my post discusses. Here are the arguments from my post about why i don't think it's a big deal:

1. You can in this case see CTV as an optimization of (tweaked) APOAS. A lot of us are doubtful about CTV
usecases for real people. So much that it was even proposed to temporarily activate it to see if it would
ever have any real traction! [2]
My point with this post was: what if we do (a slightly tweaked) BIP118, that is otherwise useful. And
if this use of covenants is really getting traction then we can roll out an optimization in the form of
CTV (or better covenants, as we'd have had more research put into it by this time).
2. CTV is mainly sold for its usage inside vaults. While i'm not convinced, a few more vbytes should not
matter for this usecase.

Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25 vbytes).
Aside, you can also use the internal key optimization with APO. But i don't think it's desirable just to save32 WU, as you can't have NUMS-ness then. [3]

> 4. Higher network-wide full-node validation costs (checking a signature is quite more expensive than hashing, and the hashing is done in both cases).

Are APO signatures more expensive to verify? If not i don't think this should be a reason to constrain us to a
much less useful construction, as the cost for the network of validating signatures already exists today. Evenif it didn't, the tradeoff of cost/usefulness needs to be considered.

> 5. As APO is currently spec'd, it would suffer from the half-spend problem: if you have multiple outputs encumbered under an APO covenant that requires the same tx sigmsg hash, it becomes possible to spend all of them together as multiple inputs in a single transaction and burn the extra to mining fees.
>
> If I'm not mistaken, I believe this makes the simple-apo-vault implementation [1] vulnerable to spending multiple vaulted outputs of the same denomination together and burning all but the first one. I asked the author for a more definitive answer on twitter [2].
>
> Fixing this requires amending BIP 118 with some new sigmsg flags (making the ANYONECANPAY behaviour optional, as mentioned in the OP).

Yes! And as i mentioned on Twitter also committing to the input index which i forgot to add in the OP here.

While i don't think the specific points are valid, i appreciate your reply and your efforts to explore the
tradeoffs between the two approaches.

Thanks,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

[1] https://bitcoin.stackexchange.com/a/91050/101498
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
[3] https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw

> This is definitely possible but also means that APO as-is isn't a CTV-replacement candidate, without first going through some more design and review iterations.
>
> shesek
>
> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>
> [1] https://github.com/darosior/simple-anyprevout-vault
> [2] https://twitter.com/shesek/status/1519874493434544128
>
> 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

[-- Attachment #2: Type: text/html, Size: 11082 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 11341 bytes --]

> This is *literally* what the post you are replying to is proposing to
solve.

I thought the changes mentioned in the OP (+ committing to the spent input
index) only solves the half-spend problem, but not the stable txids one?

There can be other inputs with a scriptSig, which doesn't get committed to
in the APO hash. I guess this isn't too common, but there might be some
cases where you would want to spend some (pre-selected) non-segwit inputs
alongside your covenant, maybe for fees. With CTV you would pre-commit to
the scriptSig which makes it non-malleable even if the script itself is.

> Hmm? You can't have channel factories without Eltoo. (Well, you can in
theory but good luck.)
> Maybe you are refering to non-interactive channel creation?

I was referring to what BIP 119 calls 'Batched Channel Creation' [0], which
is a sort of a channel factory construction under a broader definition (and
in fact was previously called that in the BIP [1]).

> The case for stable txids is less strong if we have APO (and therefore
Eltoo).

There's merit in using these factory constructs for Poon-Dryja channels
even if Eltoo was available.
I don't foresee Eltoo taking over the penalty approach entirely, but rather
the two living side by side.

(It could theoretically be possible to use APO to open Poon-Dryja channels
on top of unstable funding txids, but having stable txids makes this much
more easily integratable with existing lightning implementations, without
the invasive changes that unstable txids would bring.)

> This has been addressed over and over and over again. If a QC is able
overnight to spend a large fraction of
> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
(that would eventually become
> vulnerable when trying to use it) are worthless.

It might be the case that a sufficient fraction of supply does switch over
to QC-protected outputs in time, with only some small minority that didn't
actively switch over *and* with revealed bare pubkeys losing their funds,
which wouldn't make BTC entirely worthless. It makes sense not to want to
be in that minority, ideally without requiring further time-sensitive
active action (esp if considering long-term deep cold storage for
inheritance etc).

(This of course assumes a safe post-QC mechanism to later spend these
funds; IIUC there are some viable approaches for that using a two-step
spending procedure, where you prove knowledge of the pubkey/script preimage
while commiting to a future tx.)

> Sorry for being sarcastic, but at this point it's not fair to use
quantum-computer FUD to justify the
> activation of CTV over APO, or encourage the use of legacy transactions
over Taproot ones.

Sorry if it came off as FUDing. I don't know enough to hold a strong opinion
on whether the fear of QCs is justified or not. I know that many people on
this list don't think so, but I also think that this fear is prevalent
enough to warrant taking it into consideration (at least for features that
target long-term SoV use cases; less so for features targeted at L2 MoE
applications like lightning spacechains paypools etc).

> you can also use the internal key optimization .. you can't have
NUMS-ness then

Right, which makes this unsuitable for the vaulting use case.

> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness
units* (8.25 vbytes).

Ugh yes sorry about that! I realized after hitting send and meant to
clarify that it should've been s/vbyte/WU/ in my next reply.

> Are APO signatures more expensive to verify? .. the cost for the network
of validating signatures already exists today

Not compared to existing signature verifications, but compared to a
CTV/TXHASH-like construction.

Can anyone quantify how much of a difference this makes in practice?

> i appreciate your reply and your efforts to explore the tradeoffs between
the two approaches.

Thank you, I appreciate your efforts on this too :-)

shesek

[0]
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
[1] https://github.com/bitcoin/bips/pull/1273

On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior@protonmail.com> wrote:

> Hi Shesek,
>
> 1. The resulting txids are not stable.
>
>
> This is *literally* what the post you are replying to is proposing to
> solve.
>
>
> This property could be important for some of the proposed CTV use-cases,
> like channel factories.
>
>
> Hmm? You can't have channel factories without Eltoo. (Well, you can in
> theory but good luck.)
> Maybe you are refering to non-interactive channel creation? The case for
> stable txids is less strong if we
> have APO (and therefore Eltoo). [0]
>
>
> 2. APO will only be available on Taproot, which some people might prefer
> to avoid for long-term multi-decade vault storage due to QC concerns. (also
> see my previous post on this thread [0])
>
>
> This has been addressed over and over and over again. If a QC is able
> overnight to spend a large fraction of
> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
> (that would eventually become
> vulnerable when trying to use it) are worthless.[1]
>
> Sorry for being sarcastic, but at this point it's not fair to use
> quantum-computer FUD to justify the
> activation of CTV over APO, or encourage the use of legacy transactions
> over Taproot ones.
>
>
> 3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
> (plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
> branch*, for the taproot control block. with more branches CTV-in-taproot
> eventually becomes preferable).
>
>
> Again, this is what my post discusses. Here are the arguments from my post
> about why i don't think it's a big deal:
>
>     1. You can in this case see CTV as an optimization of (tweaked) APOAS.
> A lot of us are doubtful about CTV
>        usecases for real people. So much that it was even proposed to
> temporarily activate it to see if it would
>        ever have any real traction! [2]
>        My point with this post was: what if we do (a slightly tweaked)
> BIP118, that is otherwise useful. And
>        if this use of covenants is really getting traction then we can
> roll out an optimization in the form of
>        CTV (or better covenants, as we'd have had more research put into
> it by this time).
>     2. CTV is mainly sold for its usage inside vaults. While i'm not
> convinced, a few more vbytes should not
>        matter for this usecase.
>
> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness
> units* (8.25 vbytes).
> Aside, you can also use the internal key optimization with APO. But i
> don't think it's desirable just to save
> 32 WU, as you can't have NUMS-ness then. [3]
>
>
> 4. Higher network-wide full-node validation costs (checking a signature is
> quite more expensive than hashing, and the hashing is done in both cases).
>
>
> Are APO signatures more expensive to verify? If not i don't think this
> should be a reason to constrain us to a
> much less useful construction, as the cost for the network of validating
> signatures already exists today. Even
> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>
>
> 5. As APO is currently spec'd, it would suffer from the half-spend
> problem: if you have multiple outputs encumbered under an APO covenant that
> requires the same tx sigmsg hash, it becomes possible to spend all of them
> together as multiple inputs in a single transaction and burn the extra to
> mining fees.
>
> If I'm not mistaken, I believe this makes the simple-apo-vault
> implementation [1] vulnerable to spending multiple vaulted outputs of the
> same denomination together and burning all but the first one. I asked the
> author for a more definitive answer on twitter [2].
>
> Fixing this requires amending BIP 118 with some new sigmsg flags (making
> the ANYONECANPAY behaviour optional, as mentioned in the OP).
>
>
> Yes! And as i mentioned on Twitter also committing to the input index
> which i forgot to add in the OP here.
>
>
> While i don't think the specific points are valid, i appreciate your reply
> and your efforts to explore the
> tradeoffs between the two approaches.
>
> Thanks,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [1] https://bitcoin.stackexchange.com/a/91050/101498
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
> [3]
> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>
>
> This is definitely possible but also means that APO as-is isn't a
> CTV-replacement candidate, without first going through some more design and
> review iterations.
>
> shesek
>
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
> [1] https://github.com/darosior/simple-anyprevout-vault
> [2] https://twitter.com/shesek/status/1519874493434544128
>
>
>
> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 17616 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 12460 bytes --]

Correction: thinking about this some more, you can't actually expect to
have a stable txid if you allow additional inputs at all...

So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
commits to the number of inputs) as proposed in the OP should be sufficient
to get stable txids for single-input transactions.

(I initially thought that APO has to cover some additional tx parts for
this, but it seems that it's really just the scriptSig which is guarrnated
to be empty if you have a single input that is known to be the taproot APO
spend.)

So in overall, my (1) and (5) points are only applicable to
APO-as-currently-spec'd and not to the suggested APO revision.

On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi <nadav@shesek.info> wrote:

> > This is *literally* what the post you are replying to is proposing to
> solve.
>
> I thought the changes mentioned in the OP (+ committing to the spent input
> index) only solves the half-spend problem, but not the stable txids one?
>
> There can be other inputs with a scriptSig, which doesn't get committed to
> in the APO hash. I guess this isn't too common, but there might be some
> cases where you would want to spend some (pre-selected) non-segwit inputs
> alongside your covenant, maybe for fees. With CTV you would pre-commit to
> the scriptSig which makes it non-malleable even if the script itself is.
>
> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
> theory but good luck.)
> > Maybe you are refering to non-interactive channel creation?
>
> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
> which is a sort of a channel factory construction under a broader
> definition (and in fact was previously called that in the BIP [1]).
>
> > The case for stable txids is less strong if we have APO (and therefore
> Eltoo).
>
> There's merit in using these factory constructs for Poon-Dryja channels
> even if Eltoo was available.
> I don't foresee Eltoo taking over the penalty approach entirely, but
> rather the two living side by side.
>
> (It could theoretically be possible to use APO to open Poon-Dryja
> channels on top of unstable funding txids, but having stable txids makes
> this much more easily integratable with existing lightning implementations,
> without the invasive changes that unstable txids would bring.)
>
> > This has been addressed over and over and over again. If a QC is able
> overnight to spend a large fraction of
> > the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
> (that would eventually become
> > vulnerable when trying to use it) are worthless.
>
> It might be the case that a sufficient fraction of supply does switch over
> to QC-protected outputs in time, with only some small minority that didn't
> actively switch over *and* with revealed bare pubkeys losing their funds,
> which wouldn't make BTC entirely worthless. It makes sense not to want to
> be in that minority, ideally without requiring further time-sensitive
> active action (esp if considering long-term deep cold storage for
> inheritance etc).
>
> (This of course assumes a safe post-QC mechanism to later spend these
> funds; IIUC there are some viable approaches for that using a two-step
> spending procedure, where you prove knowledge of the pubkey/script preimage
> while commiting to a future tx.)
>
> > Sorry for being sarcastic, but at this point it's not fair to use
> quantum-computer FUD to justify the
> > activation of CTV over APO, or encourage the use of legacy transactions
> over Taproot ones.
>
> Sorry if it came off as FUDing. I don't know enough to hold a strong
> opinion on whether the fear of QCs is justified or not. I know that many
> people on this list don't think so, but I also think that this fear is
> prevalent enough to warrant taking it into consideration (at least for
> features that target long-term SoV use cases; less so for features
> targeted at L2 MoE applications like lightning spacechains paypools etc).
>
> > you can also use the internal key optimization .. you can't have
> NUMS-ness then
>
> Right, which makes this unsuitable for the vaulting use case.
>
> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
> witness units* (8.25 vbytes).
>
> Ugh yes sorry about that! I realized after hitting send and meant to
> clarify that it should've been s/vbyte/WU/ in my next reply.
>
> > Are APO signatures more expensive to verify? .. the cost for the
> network of validating signatures already exists today
>
> Not compared to existing signature verifications, but compared to a
> CTV/TXHASH-like construction.
>
> Can anyone quantify how much of a difference this makes in practice?
>
> > i appreciate your reply and your efforts to explore the tradeoffs
> between the two approaches.
>
> Thank you, I appreciate your efforts on this too :-)
>
> shesek
>
> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
> [1] https://github.com/bitcoin/bips/pull/1273
>
> On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior@protonmail.com> wrote:
>
>> Hi Shesek,
>>
>> 1. The resulting txids are not stable.
>>
>>
>> This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>>
>> This property could be important for some of the proposed CTV use-cases,
>> like channel factories.
>>
>>
>> Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> Maybe you are refering to non-interactive channel creation? The case for
>> stable txids is less strong if we
>> have APO (and therefore Eltoo). [0]
>>
>>
>> 2. APO will only be available on Taproot, which some people might prefer
>> to avoid for long-term multi-decade vault storage due to QC concerns. (also
>> see my previous post on this thread [0])
>>
>>
>> This has been addressed over and over and over again. If a QC is able
>> overnight to spend a large fraction of
>> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
>> (that would eventually become
>> vulnerable when trying to use it) are worthless.[1]
>>
>> Sorry for being sarcastic, but at this point it's not fair to use
>> quantum-computer FUD to justify the
>> activation of CTV over APO, or encourage the use of legacy transactions
>> over Taproot ones.
>>
>>
>> 3. Higher witness satisfaction cost of roughly 3x vbytes vs
>> CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of
>> a single CTV branch*, for the taproot control block. with more branches
>> CTV-in-taproot eventually becomes preferable).
>>
>>
>> Again, this is what my post discusses. Here are the arguments from my
>> post about why i don't think it's a big deal:
>>
>>     1. You can in this case see CTV as an optimization of (tweaked)
>> APOAS. A lot of us are doubtful about CTV
>>        usecases for real people. So much that it was even proposed to
>> temporarily activate it to see if it would
>>        ever have any real traction! [2]
>>        My point with this post was: what if we do (a slightly tweaked)
>> BIP118, that is otherwise useful. And
>>        if this use of covenants is really getting traction then we can
>> roll out an optimization in the form of
>>        CTV (or better covenants, as we'd have had more research put into
>> it by this time).
>>     2. CTV is mainly sold for its usage inside vaults. While i'm not
>> convinced, a few more vbytes should not
>>        matter for this usecase.
>>
>> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness
>> units* (8.25 vbytes).
>> Aside, you can also use the internal key optimization with APO. But i
>> don't think it's desirable just to save
>> 32 WU, as you can't have NUMS-ness then. [3]
>>
>>
>> 4. Higher network-wide full-node validation costs (checking a signature
>> is quite more expensive than hashing, and the hashing is done in both
>> cases).
>>
>>
>> Are APO signatures more expensive to verify? If not i don't think this
>> should be a reason to constrain us to a
>> much less useful construction, as the cost for the network of validating
>> signatures already exists today. Even
>> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>>
>>
>> 5. As APO is currently spec'd, it would suffer from the half-spend
>> problem: if you have multiple outputs encumbered under an APO covenant that
>> requires the same tx sigmsg hash, it becomes possible to spend all of them
>> together as multiple inputs in a single transaction and burn the extra to
>> mining fees.
>>
>> If I'm not mistaken, I believe this makes the simple-apo-vault
>> implementation [1] vulnerable to spending multiple vaulted outputs of the
>> same denomination together and burning all but the first one. I asked the
>> author for a more definitive answer on twitter [2].
>>
>> Fixing this requires amending BIP 118 with some new sigmsg flags (making
>> the ANYONECANPAY behaviour optional, as mentioned in the OP).
>>
>>
>> Yes! And as i mentioned on Twitter also committing to the input index
>> which i forgot to add in the OP here.
>>
>>
>> While i don't think the specific points are valid, i appreciate your
>> reply and your efforts to explore the
>> tradeoffs between the two approaches.
>>
>> Thanks,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
>> [1] https://bitcoin.stackexchange.com/a/91050/101498
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
>> [3]
>> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>>
>>
>> This is definitely possible but also means that APO as-is isn't a
>> CTV-replacement candidate, without first going through some more design and
>> review iterations.
>>
>> shesek
>>
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>> [1] https://github.com/darosior/simple-anyprevout-vault
>> [2] https://twitter.com/shesek/status/1519874493434544128
>>
>>
>>
>> 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
>>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 18651 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5558 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 4796 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6643 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Nadav Ivgi]

[-- Attachment #1: Type: text/plain, Size: 5708 bytes --]

> via `sha_sequences`

Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.

Not committing to the nSequence of other inputs gives them the freedom to
set it independently, so for example you can spend a CSV-encumbered output
alongside the covenant. And there seems to be no downside to doing this [1].

APO/APOAS already commits to the nSequence of the current input. And since
APO is Taproot-only, the scriptSig of the covenant input is guarrnated to
be empty, so it is also already committed to in a way.

However, without committing to all the nSequences which implicitly commits
to the number of inputs, the number has to be committed separately.

So my suggestion is to explicitly commit to the number of inputs, instead
of commiting to `sha_sequences`.

Cheers
shesek

[0] the additional input(s) will be third-party malleable, since their
prevouts can be replaced with an entirely different txid:vout
[1] BIP 119's rationale for committing to the nSequences is txid
malleability:
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#committing-to-the-sequences-hash



On Sat, Apr 30, 2022 at 11:09 AM Nadav Ivgi <nadav@shesek.info> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 9724 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 15821 bytes --]

>   If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]

I know this has been debated to death, but I really don't think this
argument is very convincing. First of all, why are we assuming that if for
example, "satoshi's hoard" of 5+ million bitcoins was stolen, that it would
mean bitcoin becomes worthless? To me this is an absurd assumption to make.
The thief almost certainly wouldn't want to just destroy bitcoin. But even
if they did and put it all up for sale overnight, yes it would tank
bitcoin's price *temporarily*. But in the long run, this is less than 1/3
of the supply, and it at worst could be considered monetary inflation of <
30%, and so that's the amount that the price should take a hit of: less
than 30%. Plenty of fiat currencies have survived worse.

Second of all, its incredibly unlikely that someone is suddenly going to be
able to do QC so well that they jump straight to being able to find "a
large fraction" of the private keys out there, or enough private keys to
make up a large fraction of the supply. Its far more likely that the first
quantum computers that are able to derive *any* private keys will still
take a long time (weeks? months?) to do one. If you have your bitcoins in a
segwit address, you know that they can't be stolen by a quantum computer.
You can sit back calmly, and figure out what to do next. By contrast, if
your life savings is in a taproot address, you have to drop everything with
your underwear on fire and recklessly move that stuff ASAP. Chances for
hasty mistakes is high.

But lets say someone *does* jump to being able to derive 1 private key per
minute (pretty darn fast if you ask me). It would currently take such a
machine 152 years to crack all the 80 million UTXOs in existence. By the
time there are practical quantum machines, it'll probably be at least
double that many UTXOs. If it was trying to crack revealed private keys
from mempool transactions, it could only really hit 10 out of 2000
transactions. Hashing the public key is I think is quite an effective
protection to a quantum computing attack in the vast majority of likely QC
emergence scenarios. I honestly don't understand how someone could come to
a different conclusion.

It makes a lot of sense in a world where quantum computers are now a very
real thing, to store large amounts of bitcoin in a possibly slightly less
efficient way in order to ensure that those funds can't be snatched in a QC
disaster scenario. I would be very interested to see a proposal to add the
option of having a taproot address type that doesn't expose the bare public
key.


On Fri, Apr 29, 2022 at 6:53 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Correction: thinking about this some more, you can't actually expect to
> have a stable txid if you allow additional inputs at all...
>
> So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
> commits to the number of inputs) as proposed in the OP should be sufficient
> to get stable txids for single-input transactions.
>
> (I initially thought that APO has to cover some additional tx parts for
> this, but it seems that it's really just the scriptSig which is guarrnated
> to be empty if you have a single input that is known to be the taproot APO
> spend.)
>
> So in overall, my (1) and (5) points are only applicable to
> APO-as-currently-spec'd and not to the suggested APO revision.
>
> On Fri, Apr 29, 2022 at 1:21 PM Nadav Ivgi <nadav@shesek.info> wrote:
>
>> > This is *literally* what the post you are replying to is proposing to
>> solve.
>>
>> I thought the changes mentioned in the OP (+ committing to the spent
>> input index) only solves the half-spend problem, but not the stable txids
>> one?
>>
>> There can be other inputs with a scriptSig, which doesn't get committed
>> to in the APO hash. I guess this isn't too common, but there might be some
>> cases where you would want to spend some (pre-selected) non-segwit inputs
>> alongside your covenant, maybe for fees. With CTV you would pre-commit to
>> the scriptSig which makes it non-malleable even if the script itself is.
>>
>> > Hmm? You can't have channel factories without Eltoo. (Well, you can in
>> theory but good luck.)
>> > Maybe you are refering to non-interactive channel creation?
>>
>> I was referring to what BIP 119 calls 'Batched Channel Creation' [0],
>> which is a sort of a channel factory construction under a broader
>> definition (and in fact was previously called that in the BIP [1]).
>>
>> > The case for stable txids is less strong if we have APO (and therefore
>> Eltoo).
>>
>> There's merit in using these factory constructs for Poon-Dryja channels
>> even if Eltoo was available.
>> I don't foresee Eltoo taking over the penalty approach entirely, but
>> rather the two living side by side.
>>
>> (It could theoretically be possible to use APO to open Poon-Dryja
>> channels on top of unstable funding txids, but having stable txids makes
>> this much more easily integratable with existing lightning implementations,
>> without the invasive changes that unstable txids would bring.)
>>
>> > This has been addressed over and over and over again. If a QC is able
>> overnight to spend a large fraction of
>> > the supply, your coins in your super
>> non-QC-vulnerable-bare-CTV-covenant (that would eventually become
>> > vulnerable when trying to use it) are worthless.
>>
>> It might be the case that a sufficient fraction of supply does switch
>> over to QC-protected outputs in time, with only some small minority that
>> didn't actively switch over *and* with revealed bare pubkeys losing
>> their funds, which wouldn't make BTC entirely worthless. It makes sense not
>> to want to be in that minority, ideally without requiring further
>> time-sensitive active action (esp if considering long-term deep cold
>> storage for inheritance etc).
>>
>> (This of course assumes a safe post-QC mechanism to later spend these
>> funds; IIUC there are some viable approaches for that using a two-step
>> spending procedure, where you prove knowledge of the pubkey/script preimage
>> while commiting to a future tx.)
>>
>> > Sorry for being sarcastic, but at this point it's not fair to use
>> quantum-computer FUD to justify the
>> > activation of CTV over APO, or encourage the use of legacy transactions
>> over Taproot ones.
>>
>> Sorry if it came off as FUDing. I don't know enough to hold a strong
>> opinion on whether the fear of QCs is justified or not. I know that many
>> people on this list don't think so, but I also think that this fear is
>> prevalent enough to warrant taking it into consideration (at least for
>> features that target long-term SoV use cases; less so for features
>> targeted at L2 MoE applications like lightning spacechains paypools etc).
>>
>> > you can also use the internal key optimization .. you can't have
>> NUMS-ness then
>>
>> Right, which makes this unsuitable for the vaulting use case.
>>
>> > Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>> witness units* (8.25 vbytes).
>>
>> Ugh yes sorry about that! I realized after hitting send and meant to
>> clarify that it should've been s/vbyte/WU/ in my next reply.
>>
>> > Are APO signatures more expensive to verify? .. the cost for the
>> network of validating signatures already exists today
>>
>> Not compared to existing signature verifications, but compared to a
>> CTV/TXHASH-like construction.
>>
>> Can anyone quantify how much of a difference this makes in practice?
>>
>> > i appreciate your reply and your efforts to explore the tradeoffs
>> between the two approaches.
>>
>> Thank you, I appreciate your efforts on this too :-)
>>
>> shesek
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Batched_Channel_Creation
>> [1] https://github.com/bitcoin/bips/pull/1273
>>
>> On Fri, Apr 29, 2022 at 11:31 AM darosior <darosior@protonmail.com>
>> wrote:
>>
>>> Hi Shesek,
>>>
>>> 1. The resulting txids are not stable.
>>>
>>>
>>> This is *literally* what the post you are replying to is proposing to
>>> solve.
>>>
>>>
>>> This property could be important for some of the proposed CTV use-cases,
>>> like channel factories.
>>>
>>>
>>> Hmm? You can't have channel factories without Eltoo. (Well, you can in
>>> theory but good luck.)
>>> Maybe you are refering to non-interactive channel creation? The case for
>>> stable txids is less strong if we
>>> have APO (and therefore Eltoo). [0]
>>>
>>>
>>> 2. APO will only be available on Taproot, which some people might prefer
>>> to avoid for long-term multi-decade vault storage due to QC concerns. (also
>>> see my previous post on this thread [0])
>>>
>>>
>>> This has been addressed over and over and over again. If a QC is able
>>> overnight to spend a large fraction of
>>> the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant
>>> (that would eventually become
>>> vulnerable when trying to use it) are worthless.[1]
>>>
>>> Sorry for being sarcastic, but at this point it's not fair to use
>>> quantum-computer FUD to justify the
>>> activation of CTV over APO, or encourage the use of legacy transactions
>>> over Taproot ones.
>>>
>>>
>>> 3. Higher witness satisfaction cost of roughly 3x vbytes vs
>>> CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of
>>> a single CTV branch*, for the taproot control block. with more branches
>>> CTV-in-taproot eventually becomes preferable).
>>>
>>>
>>> Again, this is what my post discusses. Here are the arguments from my
>>> post about why i don't think it's a big deal:
>>>
>>>     1. You can in this case see CTV as an optimization of (tweaked)
>>> APOAS. A lot of us are doubtful about CTV
>>>        usecases for real people. So much that it was even proposed to
>>> temporarily activate it to see if it would
>>>        ever have any real traction! [2]
>>>        My point with this post was: what if we do (a slightly tweaked)
>>> BIP118, that is otherwise useful. And
>>>        if this use of covenants is really getting traction then we can
>>> roll out an optimization in the form of
>>>        CTV (or better covenants, as we'd have had more research put into
>>> it by this time).
>>>     2. CTV is mainly sold for its usage inside vaults. While i'm not
>>> convinced, a few more vbytes should not
>>>        matter for this usecase.
>>>
>>> Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra *
>>> witness units* (8.25 vbytes).
>>> Aside, you can also use the internal key optimization with APO. But i
>>> don't think it's desirable just to save
>>> 32 WU, as you can't have NUMS-ness then. [3]
>>>
>>>
>>> 4. Higher network-wide full-node validation costs (checking a signature
>>> is quite more expensive than hashing, and the hashing is done in both
>>> cases).
>>>
>>>
>>> Are APO signatures more expensive to verify? If not i don't think this
>>> should be a reason to constrain us to a
>>> much less useful construction, as the cost for the network of validating
>>> signatures already exists today. Even
>>> if it didn't, the tradeoff of cost/usefulness needs to be considered.
>>>
>>>
>>> 5. As APO is currently spec'd, it would suffer from the half-spend
>>> problem: if you have multiple outputs encumbered under an APO covenant that
>>> requires the same tx sigmsg hash, it becomes possible to spend all of them
>>> together as multiple inputs in a single transaction and burn the extra to
>>> mining fees.
>>>
>>> If I'm not mistaken, I believe this makes the simple-apo-vault
>>> implementation [1] vulnerable to spending multiple vaulted outputs of the
>>> same denomination together and burning all but the first one. I asked the
>>> author for a more definitive answer on twitter [2].
>>>
>>> Fixing this requires amending BIP 118 with some new sigmsg flags (making
>>> the ANYONECANPAY behaviour optional, as mentioned in the OP).
>>>
>>>
>>> Yes! And as i mentioned on Twitter also committing to the input index
>>> which i forgot to add in the OP here.
>>>
>>>
>>> While i don't think the specific points are valid, i appreciate your
>>> reply and your efforts to explore the
>>> tradeoffs between the two approaches.
>>>
>>> Thanks,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
>>> [1] https://bitcoin.stackexchange.com/a/91050/101498
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
>>> [3]
>>> https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw
>>>
>>>
>>> This is definitely possible but also means that APO as-is isn't a
>>> CTV-replacement candidate, without first going through some more design and
>>> review iterations.
>>>
>>> shesek
>>>
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>>> [1] https://github.com/darosior/simple-anyprevout-vault
>>> [2] https://twitter.com/shesek/status/1519874493434544128
>>>
>>>
>>>
>>> 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
>

[-- Attachment #2: Type: text/html, Size: 22416 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Jeremy Rubin]

[-- Attachment #1: Type: text/plain, Size: 4240 bytes --]

Antoine,

One high level reason to not prefer APO is that it gets 'dangerously close'
to fully recursive covenants.

E.g., just by tweaking APO to use a Schnorr signature without PK
commitment, Pubkey Recovery would be possible, and fully recursive
covenants could be done.

Short of that type of modification, you can still do a "trusted setup" key
deletion covenant with APO and have a fully recursive covenant set up. E.g.

<1 || N-N MuSig> APO

where the N-N MuSig pregenerates a signature of a transaction that commits
to an output with itself, e.g., using SIGHASH_SINGLE.

By itself, this is not super useful, but does create the type of thing that
people might worry about with a recursive covenant since after
initialization it is autonomous.

One use case for this might be, for example, a spacechain backbone that
infinitely iterates, so it isn't entirely useless.

If other opcodes are added, such as OP_IN_OUT_AMOUNT, then you can get all
sorts of recursive covenant interesting stuff on top of that, since you
could pre-sign e.g. for a quanitzed vault a number of different
deposit/withdraw programs as well as increasing balances depending on
timeout waited.


Therefore, I think reasonable people might discriminate the "complexity
class" of the design space available with just CTV v.s. APO.

In contrast, the approach of smaller independent steps:

1) Adding CTV
2) Adding CSFS (enables APO-like behavior, sufficient for Eltoo)
3) Adding flags to CTV, similar to TXHASH, or just adding TXHASH (enables
full covenants)
4) Ergonomic OPCodes for covenants like TLUV, EcTweak, MAST building, etc
(enables efficient covenants)

is a much more granular path where we are able to cleanly 'level up' into
each covenant complexity class only if we deem it to be safe.

<redacted>comment about timelines to produce a modified APO</redacted>

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>

On Fri, Apr 22, 2022 at 4:23 AM 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
>

[-- Attachment #2: Type: text/html, Size: 9224 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Swambo, Jacob]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

Thanks Darosior for your response.

I see now that APOAS (e.g. with ANYONECANPAY and/or SINGLE) and CTV (with less restrictive templates) fall prey to the same trade-off between flexibility and safety. So I retract my statement about that 'point in favour of OP_CTV'. It would be nice to by-pass the trade-off, but it seems to be unavoidable. That begs the question, why would we want to have a way to commit to less restrictive templates?

Firstly, I posit that if a transaction does not allow RBF, then it would be very difficult for an attacker to repackage parts of the transaction into a malicious alternative and rebroadcast it before it reaches the mempool of the majority of nodes, who would then reject the malicious alternative.

Secondly, some covenant-based applications aren't as critical as others, and it may well be acceptable to take the risk of using something like ANYONECANPAY|ALL even with RBF enabled.

Third, in a trusted multi-party context you can safely make use of flexible signature messages. Let's say there are 3 people and a UTXO with the following locking script as a single leaf in the tapscript:

<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SINGLE:signature_covenant_tx> <covenant_PK> OP_CHECKSIG

And they produce this witness:

<SINGLE:sig_1> <ALL:sig_2>

The second participant can, for example, add a change output before signing. <sig_1> is not sufficient and so can't be repackaged without the authorisation of participant 2.


The additional flexibility through composing APOAS with other SIGHASH modes, and the ability to re-bind covenant transactions to different UTXOs allows protocol designers to do more with APOAS covenants than with CTV covenants (as currently spec'd). I'm not yet convinced that BIP-118 is totally safe, but I think the debate recently is part of that maturation process and I'm glad for it.


Jacob Swambo


[-- Attachment #2: Type: text/html, Size: 6159 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[darosior]

[-- Attachment #1: Type: text/plain, Size: 4429 bytes --]

Hi Jacob,

I think you are a bit confused about how CTV and (tweaked) APO covenants compare. Both would commit to the
same template, so one isn't "safer" than the other. Just more efficient in how it commits to the template.
Replies on the specifics inline.

> While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.

In the long term, we'd hopefully have more powerful covenants to enable more interesting applications. At this
point CTV would be an optimisation for these covenant constructions instead of an APO one.
My request for feedback was more about the short term, where some are requesting the activation of CTV to
start playing with covenants before we settle on the way forward to more useful covenant. Not that i'm in
favour of it, but if it gains sufficient traction then i believe there is a case for instead doing a tweaked
APO that would optionally commit to the input index, nSequences, etc..[0] I think this addresses the technical
debt concerns of CTV once we have more interesting covenants, as no covenant can entirely emulate a signature
hash type.

> With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications.

What do you mean "tied to the transaction validation"? To me "transaction validation" is what a node does to
check whether a block is valid, but you probably mean something else here.
With APOAS-based covenants, the signature message *is* the covenant commitment. I don't see how it is coupled
to anything else. I also don't see how it could ever differ in safety or flexibility with another
hashed-template approach (CTV) if the template is the same.

> E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay.

Indeed the APO approach is more flexible as sighash types may be combined. You can opt-in to more
malleability. I don't think it's a bad thing. Now, sure, the commitment may be replayed, but it's inherent to
any commitment that doesn't commit to the prevout (whether it is CTV or APO, or any other type of templated
covenant that you'd place in the ScriptPubKey) otherwise you'd have a circular hash dependency.
If you are talking about the "half spend" by which two coins with the same covenant get spent in the same
transaction, then committing to the input index fixes this. Interestingly the instance you give *does* commit
to the input index without any tweak to the current APO proposal.

> If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off.

CTV doesn't "separate the signature and the commitment", it doesn't need a signature. Sure one can be added to
further restrict a spending path, but it isn't necessary since the transaction is pre-defined and can't be
malleated. It also sounds like you imply the APO covenant is using a "real" signature. It's not. The pubkey
may well be G. The signature is just a roundabout way to access the hash. So if you wanted to have, say, a
covenant only available to a participant you'd go the same way with either CTV or APO covenants:
<covenant sig> <0x01 G> OP_CHECKSIGVERIFY <Alice pubkey> OP_CHECKSIG
<tx hash> OP_CTV OP_VERIFY <Alice pubkey> OP_CHECKSIG

> The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.

TXHASH would definitely enable more utility. Additional templates with new CTV versions would require a new
soft fork for new (hardcoded) usecases. But i'm not going to restart the conversation around the benefits of
slightly more general covenant primitives [1]. :-)

Antoine

[0] See the OP for rationale[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

[0] Cf the OP for the rationale

[-- Attachment #2: Type: text/html, Size: 6037 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Swambo, Jacob]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Hi,

While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.

With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications. E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay. If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off. The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.

Best regards,

Jacob Swambo

[-- Attachment #2: Type: text/html, Size: 1555 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 5455 bytes --]

Hi pushd.
Would you mind clarifying what you mean by BIP118 being a premature idea?
SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was
first proposed in the original Lightning Network whitepaper back in 2015.
It has been discussed on and off for many years now. I would not call it a
premature idea.

Now, the revised "Taprooted" version called ANYPREVOUT is a couple of years
old, so going with the NOINPUT version could be a safer bet (though that's
a bit ridiculous in my opinion).

Regarding that you do not find use-cases interesting. That's all fine I
suppose, but in the Lightning Network scene, I think it's fair to say that
there's widespread enthusiasm in getting a working eltoo solution, which
necessitates something like NOINPUT/ANYPREVOUT.
And even if eltoo wouldn't happen, enabling spacechains, covenants and
blind statechains seem like sufficient use-cases to me.

Cheers
Hampus

On Fri, Apr 22, 2022 at 9:32 PM pushd 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.
>
>
> NACK for the below reasons:
>
> - Premature idea
> - I do not find use cases interesting
> - We are still in research phase of implementing covenants in bitcoin and
> looking for the best proposal
> - Taproot soft fork was recently activated and its too soon
> - Not enough documentation available
> - Could not find any pull request in core for BIP 118 that can be reviewed
> - Not enough tools available for testing
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Friday, April 22nd, 2022 at 5:30 PM,
> bitcoin-dev-request@lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +0000
> From: darosior darosior@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
>
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> *******************************************
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7638 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[pushd]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

Hi Luke,

> But none of this ST nonsense, please. That alone is a reason to oppose it.

Agree. Any soft fork that uses only speedy trial should be opposed. There are few other reasons to oppose it as well:

- Premature idea
- Use cases are not interesting for all users
- We are still in research phase of implementing covenants in bitcoin and looking for the best proposal
- Taproot soft fork was recently activated and its too soon
- Not enough documentation available
- Could not find any pull request in core for BIP 118 that can be reviewed
- Not enough tools available for testing

I am planning to maintain a page for all the NACKs against BIP 118 based on this thread. I am assuming you don't mind including your name in it.

pushd

---
parallel lines meet at infinity?

> ------------------------------
>
> Message: 3
> Date: Fri, 22 Apr 2022 17:01:14 +0000
> From: Luke Dashjr luke@dashjr.org
>
> To: bitcoin-dev@lists.linuxfoundation.org, darosior
> darosior@protonmail.com
>
> Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID: 202204221701.15307.luke@dashjr.org
>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> There's no reason for before/after/in place. We have version bits specifically
> so we can have multiple deployments in parallel.
>
> But none of this ST nonsense, please. That alone is a reason to oppose it.
>
> Luke
>
> On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev 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-me
>> ssage.
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 42
> *******************************************

[-- Attachment #2: Type: text/html, Size: 5087 bytes --]

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[pushd]

[-- Attachment #1: Type: text/plain, Size: 4168 bytes --]

> I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of (or before doing) BIP119.

NACK for the below reasons:

- Premature idea
- I do not find use cases interesting
- We are still in research phase of implementing covenants in bitcoin and looking for the best proposal
- Taproot soft fork was recently activated and its too soon
- Not enough documentation available
- Could not find any pull request in core for BIP 118 that can be reviewed
- Not enough tools available for testing

pushd
---

parallel lines meet at infinity?

------- Original Message -------
On Friday, April 22nd, 2022 at 5:30 PM, bitcoin-dev-request@lists.linuxfoundation.org wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +0000
> From: darosior darosior@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> *******************************************

[-- Attachment #2: Type: text/html, Size: 5464 bytes --]