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 remy...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
