📅 Original date posted:2022-04-22
📝 Original message:I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
(or before doing) BIP119.
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and
implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than
CTV's.
SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive to use. But we can consider CTV
an optimization of APO-AS covenants.
CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to
implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still
useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for
a potential vault user.
If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain
usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In
the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind
statechains, etc..[1]).
Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that
BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.
Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables
CTV's features, for the same reason they'd oppose BIP119.
[0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also
`sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.
[1] https://anyprevout.xyz/ "Use Cases" section
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-07 23:07:56
in reply to nevent1q…pawz
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-07 23:07:56Event JSON
{
"id": "80894dcdc05c54aec816bd5822a2781c3f82998695e953bf19210935ee3c3ccc",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686179276,
"kind": 1,
"tags": [
[
"e",
"744ae2e156228361733cf74acfff3433f11541ee820fe9185cc72f3c98beb11b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-04-22\n📝 Original message:I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of\n(or before doing) BIP119.\n\nSIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and\nimplemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than\nCTV's.\n\nSIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made optional [0], can emulate CTV just fine.\nSure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive to use. But we can consider CTV\nan optimization of APO-AS covenants.\n\nCTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to\nimplement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still\nuseful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for\na potential vault user.\n\nIf after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain\nusage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In\nthe meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind\nstatechains, etc..[1]).\n\n\nGiven the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that\nBIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.\nActually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables\nCTV's features, for the same reason they'd oppose BIP119.\n\n\n[0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also\n`sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.\n\n[1] https://anyprevout.xyz/ \"Use Cases\" section",
"sig": "7eafdda1699a7b8913c4ea6c69a525c4e6cf400d18d5b43cd76db7914a908e4b7e2f7cf52dbba38e914905b7a5099fddaed6a059810d7a01c657373fa02d10bb"
}