public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] ANYPREVOUT in place of CTV
@ 2022-04-22 17:14 pushd
  0 siblings, 0 replies; 26+ messages in thread
From: pushd @ 2022-04-22 17:14 UTC (permalink / raw)
  To: luke; +Cc: bitcoin-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] ANYPREVOUT in place of CTV
@ 2022-05-03 16:40 Swambo, Jacob
  0 siblings, 0 replies; 26+ messages in thread
From: Swambo, Jacob @ 2022-05-03 16:40 UTC (permalink / raw)
  To: bitcoin-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] ANYPREVOUT in place of CTV
@ 2022-04-29 13:22 Swambo, Jacob
  2022-05-03 10:38 ` darosior
  0 siblings, 1 reply; 26+ messages in thread
From: Swambo, Jacob @ 2022-04-29 13:22 UTC (permalink / raw)
  To: bitcoin-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] ANYPREVOUT in place of CTV
@ 2022-04-22 13:35 pushd
  2022-04-25 13:34 ` Hampus Sjöberg
  0 siblings, 1 reply; 26+ messages in thread
From: pushd @ 2022-04-22 13:35 UTC (permalink / raw)
  To: darosior; +Cc: bitcoin-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [bitcoin-dev] ANYPREVOUT in place of CTV
@ 2022-04-22 11:11 darosior
  2022-04-22 11:44 ` rot13maxi
                   ` (9 more replies)
  0 siblings, 10 replies; 26+ messages in thread
From: darosior @ 2022-04-22 11:11 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2022-05-03 16:40 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22 17:14 [bitcoin-dev] ANYPREVOUT in place of CTV pushd
  -- strict thread matches above, loose matches on Subject: below --
2022-05-03 16:40 Swambo, Jacob
2022-04-29 13:22 Swambo, Jacob
2022-05-03 10:38 ` darosior
2022-04-22 13:35 pushd
2022-04-25 13:34 ` Hampus Sjöberg
2022-04-22 11:11 darosior
2022-04-22 11:44 ` rot13maxi
2022-04-22 11:54   ` darosior
2022-04-22 17:01 ` Luke Dashjr
2022-04-24 20:41 ` Richard Myers
2022-04-25 13:35   ` darosior
2022-04-25 16:35     ` darosior
2022-04-25  1:46 ` Erik Aronesty
2022-04-25 16:35 ` Nadav Ivgi
2022-04-25 16:57 ` Nadav Ivgi
2022-04-26 20:13 ` Jeremy Rubin
2022-04-29  5:08 ` Nadav Ivgi
2022-04-29  8:30   ` darosior
2022-04-29 10:21     ` Nadav Ivgi
2022-04-29 11:40       ` Nadav Ivgi
2022-05-01 23:35         ` Billy Tetrud
2022-04-30  8:09 ` Nadav Ivgi
2022-04-30 11:15   ` Greg Sanders
2022-05-01 14:25   ` Nadav Ivgi
2022-05-03 15:51 ` Jeremy Rubin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox