📅 Original date posted:2022-04-29
📝 Original message:Here's a summary of the trade-offs I see for using APO as a CTV alternative:
1. The resulting txids are not stable.
CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire transaction graph descending from it).
This property could be important for some of the proposed CTV use-cases,
like channel factories.
2. APO will only be available on Taproot, which some people might prefer to
avoid for long-term multi-decade vault storage due to QC concerns. (also
see my previous post on this thread [0])
3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot
(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV
branch*, for the taproot control block. with more branches CTV-in-taproot
eventually becomes preferable).
4. Higher network-wide full-node validation costs (checking a signature is
quite more expensive than hashing, and the hashing is done in both cases).
5. As APO is currently spec'd, it would suffer from the half-spend problem:
if you have multiple outputs encumbered under an APO covenant that requires
the same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.
If I'm not mistaken, I believe this makes the simple-apo-vault
implementation [1] vulnerable to spending multiple vaulted outputs of the
same denomination together and burning all but the first one. I asked the
author for a more definitive answer on twitter [2].
Fixing this requires amending BIP 118 with some new sigmsg flags (making
the ANYONECANPAY behaviour optional, as mentioned in the OP).
This is definitely possible but also means that APO as-is isn't a
CTV-replacement candidate, without first going through some more design and
review iterations.
shesek
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
[1] https://github.com/darosior/simple-anyprevout-vault
[2] https://twitter.com/shesek/status/1519874493434544128
On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/08486216/attachment.html>;
Nadav Ivgi [ARCHIVE] /
npub1f2…ydpll
2023-06-07 23:08:03
in reply to nevent1q…jr5n
Author Public Key
npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpllPublished at
2023-06-07 23:08:03Event JSON
{
"id": "66500f8472a881f559185b7f8b9f55be7a84b19aaa690d7a2dc62dc21223e54b",
"pubkey": "4a9c50edfac56c5e90e382fdea7977edd0a5a46b6be7aad0461ae0075d9d2407",
"created_at": 1686179283,
"kind": 1,
"tags": [
[
"e",
"744ae2e156228361733cf74acfff3433f11541ee820fe9185cc72f3c98beb11b",
"",
"root"
],
[
"e",
"16101bf5b8819c15f031124dea5062495ede853e73bee1e42d8000c135661ab9",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-04-29\n📝 Original message:Here's a summary of the trade-offs I see for using APO as a CTV alternative:\n\n1. The resulting txids are not stable.\n\nCTV commits to enough tx information such that given the txid:vout of the\ncovenant-encumbered output, you can predict the txid of the spending tx\npermitted by CTV (and of the entire transaction graph descending from it).\n\nThis property could be important for some of the proposed CTV use-cases,\nlike channel factories.\n\n2. APO will only be available on Taproot, which some people might prefer to\navoid for long-term multi-decade vault storage due to QC concerns. (also\nsee my previous post on this thread [0])\n\n3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot\n(plus 33 extra vbytes vs CTV-in-segwitv0 *in the case of a single CTV\nbranch*, for the taproot control block. with more branches CTV-in-taproot\neventually becomes preferable).\n\n4. Higher network-wide full-node validation costs (checking a signature is\nquite more expensive than hashing, and the hashing is done in both cases).\n\n5. As APO is currently spec'd, it would suffer from the half-spend problem:\nif you have multiple outputs encumbered under an APO covenant that requires\nthe same tx sigmsg hash, it becomes possible to spend all of them together\nas multiple inputs in a single transaction and burn the extra to mining\nfees.\n\nIf I'm not mistaken, I believe this makes the simple-apo-vault\nimplementation [1] vulnerable to spending multiple vaulted outputs of the\nsame denomination together and burning all but the first one. I asked the\nauthor for a more definitive answer on twitter [2].\n\nFixing this requires amending BIP 118 with some new sigmsg flags (making\nthe ANYONECANPAY behaviour optional, as mentioned in the OP).\n\nThis is definitely possible but also means that APO as-is isn't a\nCTV-replacement candidate, without first going through some more design and\nreview iterations.\n\nshesek\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html\n[1] https://github.com/darosior/simple-anyprevout-vault\n[2] https://twitter.com/shesek/status/1519874493434544128\n\n\n\nOn Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I would like to know people's sentiment about doing (a very slightly\n\u003e tweaked version of) BIP118 in place of\n\u003e (or before doing) BIP119.\n\u003e\n\u003e SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for\n\u003e over 6 years. It presents proven and\n\u003e implemented usecases, that are demanded and (please someone correct me if\n\u003e i'm wrong) more widely accepted than\n\u003e CTV's.\n\u003e\n\u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made\n\u003e optional [0], can emulate CTV just fine.\n\u003e Sure then you can't have bare or Segwit v0 CTV, and it's a bit more\n\u003e expensive to use. But we can consider CTV\n\u003e an optimization of APO-AS covenants.\n\u003e\n\u003e CTV advocates have been presenting vaults as the flagship usecase.\n\u003e Although as someone who've been trying to\n\u003e implement practical vaults for the past 2 years i doubt CTV is necessary\n\u003e nor sufficient for this (but still\n\u003e useful!), using APO-AS covers it. And it's not a couple dozen more virtual\n\u003e bytes that are going to matter for\n\u003e a potential vault user.\n\u003e\n\u003e If after some time all of us who are currently dubious about CTV's stated\n\u003e usecases are proven wrong by onchain\n\u003e usage of a less efficient construction to achieve the same goal, we could\n\u003e roll-out CTV as an optimization. In\n\u003e the meantime others will have been able to deploy new applications\n\u003e leveraging ANYPREVOUT (Eltoo, blind\n\u003e statechains, etc..[1]).\n\u003e\n\u003e\n\u003e Given the interest in, and demand for, both simple covenants and better\n\u003e offchain protocols it seems to me that\n\u003e BIP118 is a soft fork candidate that could benefit more (if not most of)\n\u003e Bitcoin users.\n\u003e Actually i'd also be interested in knowing if people would oppose the\n\u003e APO-AS part of BIP118, since it enables\n\u003e CTV's features, for the same reason they'd oppose BIP119.\n\u003e\n\u003e\n\u003e [0] That is, to not commit to the other inputs of the transaction (via\n\u003e `sha_sequences` and maybe also\n\u003e `sha_amounts`). Cf\n\u003e https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message\n\u003e .\n\u003e\n\u003e [1] https://anyprevout.xyz/ \"Use Cases\" section\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/08486216/attachment.html\u003e",
"sig": "63141d41f64a892bf887a5018bf8c4e673ef08345b584ab800e1613fd9e097b860321690cad1c87dcc43db65d36da52ffb589b65282cc2ac8bbe4483746dbea0"
}