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

[darosior <darosior@protonmail.com>]

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