📅 Original date posted:2022-04-24
📝 Original message: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
Richard Myers [ARCHIVE] /
npub12j…hfxgj
2023-06-07 23:08:00
in reply to nevent1q…w7qe
Author Public Key
npub12jllrss5nmygfhg7j9ztk2te80t96kumx7cllfc29skut6phqh5qfhfxgjSeen on
wss://relay.nostr.bandPublished at
2023-06-07 23:08:00Event JSON
{
"id": "9e27ada79cab997d84d94f81755a2e62966fc3d9a9b95442b49a71b5b06988c8",
"pubkey": "54bff1c2149ec884dd1e9144bb29793bd65d5b9b37b1ffa70a2c2dc5e83705e8",
"created_at": 1686179280,
"kind": 1,
"tags": [
[
"e",
"744ae2e156228361733cf74acfff3433f11541ee820fe9185cc72f3c98beb11b",
"",
"root"
],
[
"e",
"bd298ec5ac32588d6a114d59935bc94d204886fe737f83d9c28eff438b07c399",
"",
"reply"
],
[
"p",
"7866e39300a17990d3d88285e5fe24e019b0dfdd93c220c6d02f67095af5f70e"
]
],
"content": "📅 Original date posted:2022-04-24\n📝 Original message:Hi darosior,\n\nThanks for sharing your thoughts on this.\n\n\u003e I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of\n\u003e (or before doing) BIP119.\n\nSounds 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\n\u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made optional [0], can emulate CTV just fine.\n\nFor 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\nIn 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\nI 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\nIncluding 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\nThe BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.\n\n -- Richard",
"sig": "0223b33d6d815313dc41c488dd5cab75b3126d4885731647a6ca937f4f37c2a5b03f24a564fd171d577a748633749c4a485785e9d3494aba790163ee8b3c306c"
}