📅 Original date posted:2022-04-25
📝 Original message: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 at 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 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-07 23:08:00
in reply to nevent1q…763k
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-07 23:08:00Event JSON
{
"id": "733f1685599264b89ce273ff97ef96e6f0c16895cd1c020c82a770369a07c695",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686179280,
"kind": 1,
"tags": [
[
"e",
"744ae2e156228361733cf74acfff3433f11541ee820fe9185cc72f3c98beb11b",
"",
"root"
],
[
"e",
"7e5be53c349472574dc52281a0bd40874593d02faa4130212dd0d41eb94c5e81",
"",
"reply"
],
[
"p",
"0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2"
]
],
"content": "📅 Original date posted:2022-04-25\n📝 Original message: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.\n\n\u003e \u003e a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?\n\u003e\n\u003e 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\n\nThe comparison was already done by Anthony Towns.\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017036.html\n\nJeremy Rubin already pointed out that it missed committing to the nSequences hash and number of inputs (and optionally scriptSigs).\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html\n\n\n------- Original Message -------\nLe lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\n\u003e Hi Richard,\n\u003e\n\u003e \u003e Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do\n\u003e\n\u003e compete for scarce reviewer time\n\u003e\n\u003e Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose\n\u003e SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.\n\u003e\n\u003e \u003e For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there\n\u003e\n\u003e a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?\n\u003e\n\u003e 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\n\u003e ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are\n\u003e the number of inputs and the hash of the inputs' sequences [1].\n\u003e Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can\n\u003e be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV\n\u003e completely it should be optional.\n\u003e\n\u003e\n\u003e Antoine\n\u003e\n\u003e [0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification\n\u003e [1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message\n\u003e [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\n\u003e\n\u003e\n\u003e ------- Original Message -------\n\u003e Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers remyers at yakshaver.org a écrit :\n\u003e\n\u003e\n\u003e\n\u003e \u003e Hi darosior,\n\u003e \u003e\n\u003e \u003e Thanks for sharing your thoughts on this.\n\u003e \u003e\n\u003e \u003e \u003e I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of\n\u003e \u003e \u003e (or before doing) BIP119.\n\u003e \u003e\n\u003e \u003e 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.\n\u003e \u003e\n\u003e \u003e \u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made optional [0], can emulate CTV just fine.\n\u003e \u003e\n\u003e \u003e 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?\n\u003e \u003e\n\u003e \u003e 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.\n\u003e \u003e\n\u003e \u003e 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?\n\u003e \u003e\n\u003e \u003e 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.\n\u003e \u003e\n\u003e \u003e The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.\n\u003e \u003e\n\u003e \u003e -- Richard\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "1a169dd6de0ef40138853276a61d7ba691e78782cd3ce16920882fc7e3e12ef4e001788da6d64d10a702018163a356ca7b5efca95b60f732c6cce779849de4ec"
}