Date: Mon, 25 Apr 2022 13:35:48 +0000
To: Richard Myers <remyers@yakshaver.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <vUv4gRXGegam5vWJosPS7rCNBOnH-B2hCok5QYXfwdpLme_cg7tAXoKvH3AU3lKE-BZ-IIq4hvtGnqytZitdS43kgAFwSQJvLPaO2tRwqEA=@protonmail.com>
In-Reply-To: <edZpe6R4qRm7fk8l49O6QkNBI-ViHKR3IozFUt6IuHxujshBRWoitjaOJJy_fk9njEG4woUdOPeKY8Vy87G22KSrOr2A7XHkYh-YSbzQiNs=@yakshaver.org>
References: <p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com>
 <edZpe6R4qRm7fk8l49O6QkNBI-ViHKR3IozFUt6IuHxujshBRWoitjaOJJy_fk9njEG4woUdOPeKY8Vy87G22KSrOr2A7XHkYh-YSbzQiNs=@yakshaver.org>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Precedence: list

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 op=
pose CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about activation of anything at thi=
s point is premature.


> For someone not as versed in CTV, why is it necessary that ANYONECANPAY b=
e 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 c=
ommits 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 be=
haviour of ANYONECANPAY that can
be combined with other signature hash types [1]. Thus APO_AS makes ACP mand=
atory, 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#signatur=
e-message
[2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3=
c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitc=
oin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cp=
p#L1517-L1522


------- Original Message -------
Le dimanche 24 avril 2022 =C3=A0 10:41 PM, Richard Myers <remyers@yakshaver=
.org> a =C3=A9crit :


> Hi darosior,
>
> Thanks for sharing your thoughts on this.
>
> > I would like to know people's sentiment about doing (a very slightly tw=
eaked 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 orde=
ring will necessarily be driven by reviewer's priorities. My priority is el=
too which is why I focus on BIP-118.
>
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made op=
tional [0], can emulate CTV just fine.
>
>
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY b=
e optional to emulate CTV? Is there a write-up that explains how APO-AS w/o=
ut 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 e=
ltoo. Settlement txs in eltoo use just APO and do not necessarily need to b=
e paired with ANYONECANPAY.
>
> I would guess making ANYONECANPAY the default for APO-AS was a way to squ=
eeze 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 se=
ttled to_self balance. How to rejigger the sighash flags to accommodate bot=
h APO and GROUP may be worth some discussion.
>
> The BIP-118 proposal will certainly benefit from having input from review=
ers looking at other protocols than eltoo.
>
> -- Richard