darosior [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-25 📝 Original message:Hi Richard, > Sounds good ...
📅 Original date posted:2022-04-25
📝 Original message: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 at 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
📝 Original message: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 at 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