📅 Original date posted:2022-04-26
📝 Original message:> > i doubt CTV is necessary nor sufficient for this
> I would be interested to hear more on this.
A lot of people have been conflating vaults and covenants, especially lately. I believe we should
differentiate more Bitcoin vaults, a scheme that defines a "staged transaction process" [0], and Bitcoin
covenants. I find that there was a lot of confusion spread around that. Everything was a vault, from the
marketing of a mobile wallet with a 2of3 account to a covenant scheme. ( :)
It led to the confusion that a Bitcoin covenant would be necessary in order to have a Bitcoin vault. It's
incorrect: https://github.com/revault/practical-revault/blob/master/introduction.md (or [1], but albeit pretty
clever, i don't think it's practical).
Now, CTV is useful for Bitcoin vaults. For instance i believe it's useful to pre-commit to a Cancel
transaction directly in the Unvault Script. This matters a lot as today you need to be sure that your
watchtowers (or any other network monitor) have had the Cancel transaction signature of all participants in
the vault before you sign the Unvault transaction.
A covenant, as simple as CTV, fixes this. It makes sure that not only any Unvault you sign can be Canceled,
but also that when you spin up a new watchtower you don't need to send to it all the signatures for all the
current vaults. Of course you'd want to add some secret here to avoid the annoyance of all your Unvaults being
able to be canceled by some rando on the network. But you can derive them from a secret shared only once.
Also on the topic of reducing interactivity, i think that CTV or another more powerful covenants that allows
to commit to all parts of a transaction (for malleability) can be useful for the complicated issue of fee
bumping [2].
However, it's not sufficient. You are not going to be able to receive coins on a CTV that commits to the
Unvault (whose output would commit to either the Cancel immediately, or something else after a delay). It
would be an enormous footgun. For this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a much more
interesting direction.
Furthermore, committing entirely to the withdrawal amounts in advance is very impractical. It is the one
largest UX barrier in my opinion. Users don't think in coins, but in amount to transfer. In order to have an
almost decent UX you would have to prepare a first stage transaction that creates a nice (what is nice? It's
very hard to reason about) distribution of coin amounts. This is a big tradeoff between usability and cost
(granularity). Of course it's not new to CTV, It's an issue today with Revault. It's just a problem faced by
today's implementation(s) (i don't know of any other "real" vault implementation) of Bitcoin vaults that CTV
does not solve.
I realise that you might not care to receive coins on a single-sig Script and have a vaulting step in a
single-party situation. I guess i just think vaults are more interesting in organisational situations, where a
set of participants only marginally trust another one (that may be a subset) and want to both limit the amount
they have access to and apply policies on how they would use the funds.
Antoine
[0] All vaults architectures i know of are characterized by the necessity to unlock the funds in multiple
stages, one of which is timelocked.
[1] https://arxiv.org/abs/2005.11776
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
------- Original Message -------
Le lundi 25 avril 2022 à 6:57 PM, Nadav Ivgi <nadav at shesek.info> a écrit :
> darosior via bitcoin-dev wrote:> i doubt CTV is necessary nor sufficient for this
>
> I would be interested to hear more on this.
>
> Is it not necessary because you can exchange and store pre-signed transactions instead?
>
> What purpose is it not sufficient for? There are some vault designs out there that are able to achieve interesting properties with CTV, like James O'Beirne's simple-ctv-vault:
>
> https://github.com/jamesob/simple-ctv-vault
> (the basic design expressed in Minsc: https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)
>
> 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/20220426/0c24b9fb/attachment-0001.html>;
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-07 23:08:19
in reply to nevent1q…45xj
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-07 23:08:19Event JSON
{
"id": "3a575cd75d3f6ac88b34565199e02a48f21a379138796b9f1f0c587c9bf9b30e",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686179299,
"kind": 1,
"tags": [
[
"e",
"461cbd6378876a6ae983ec11e70dc81335738285b1cd544a0d497303262f1d5a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-04-26\n📝 Original message:\u003e \u003e i doubt CTV is necessary nor sufficient for this\n\n\u003e I would be interested to hear more on this.\n\nA lot of people have been conflating vaults and covenants, especially lately. I believe we should\ndifferentiate more Bitcoin vaults, a scheme that defines a \"staged transaction process\" [0], and Bitcoin\ncovenants. I find that there was a lot of confusion spread around that. Everything was a vault, from the\nmarketing of a mobile wallet with a 2of3 account to a covenant scheme. ( :)\nIt led to the confusion that a Bitcoin covenant would be necessary in order to have a Bitcoin vault. It's\nincorrect: https://github.com/revault/practical-revault/blob/master/introduction.md (or [1], but albeit pretty\nclever, i don't think it's practical).\n\nNow, CTV is useful for Bitcoin vaults. For instance i believe it's useful to pre-commit to a Cancel\ntransaction directly in the Unvault Script. This matters a lot as today you need to be sure that your\nwatchtowers (or any other network monitor) have had the Cancel transaction signature of all participants in\nthe vault before you sign the Unvault transaction.\nA covenant, as simple as CTV, fixes this. It makes sure that not only any Unvault you sign can be Canceled,\nbut also that when you spin up a new watchtower you don't need to send to it all the signatures for all the\ncurrent vaults. Of course you'd want to add some secret here to avoid the annoyance of all your Unvaults being\nable to be canceled by some rando on the network. But you can derive them from a secret shared only once.\nAlso on the topic of reducing interactivity, i think that CTV or another more powerful covenants that allows\nto commit to all parts of a transaction (for malleability) can be useful for the complicated issue of fee\nbumping [2].\n\nHowever, it's not sufficient. You are not going to be able to receive coins on a CTV that commits to the\nUnvault (whose output would commit to either the Cancel immediately, or something else after a delay). It\nwould be an enormous footgun. For this, i believe something like TLUV with IN_OUT_AMOUNT [3] is a much more\ninteresting direction.\nFurthermore, committing entirely to the withdrawal amounts in advance is very impractical. It is the one\nlargest UX barrier in my opinion. Users don't think in coins, but in amount to transfer. In order to have an\nalmost decent UX you would have to prepare a first stage transaction that creates a nice (what is nice? It's\nvery hard to reason about) distribution of coin amounts. This is a big tradeoff between usability and cost\n(granularity). Of course it's not new to CTV, It's an issue today with Revault. It's just a problem faced by\ntoday's implementation(s) (i don't know of any other \"real\" vault implementation) of Bitcoin vaults that CTV\ndoes not solve.\nI realise that you might not care to receive coins on a single-sig Script and have a vaulting step in a\nsingle-party situation. I guess i just think vaults are more interesting in organisational situations, where a\nset of participants only marginally trust another one (that may be a subset) and want to both limit the amount\nthey have access to and apply policies on how they would use the funds.\n\nAntoine\n\n[0] All vaults architectures i know of are characterized by the necessity to unlock the funds in multiple\nstages, one of which is timelocked.\n[1] https://arxiv.org/abs/2005.11776\n[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020122.html[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html\n\n------- Original Message -------\nLe lundi 25 avril 2022 à 6:57 PM, Nadav Ivgi \u003cnadav at shesek.info\u003e a écrit :\n\n\u003e darosior via bitcoin-dev wrote:\u003e i doubt CTV is necessary nor sufficient for this\n\u003e\n\u003e I would be interested to hear more on this.\n\u003e\n\u003e Is it not necessary because you can exchange and store pre-signed transactions instead?\n\u003e\n\u003e What purpose is it not sufficient for? There are some vault designs out there that are able to achieve interesting properties with CTV, like James O'Beirne's simple-ctv-vault:\n\u003e\n\u003e https://github.com/jamesob/simple-ctv-vault\n\u003e (the basic design expressed in Minsc: https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4)\n\u003e\n\u003e On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\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 (or before doing) BIP119.\n\u003e\u003e\n\u003e\u003e SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and\n\u003e\u003e implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than\n\u003e\u003e CTV's.\n\u003e\u003e\n\u003e\u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made optional [0], can emulate CTV just fine.\n\u003e\u003e 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\n\u003e\u003e an optimization of APO-AS covenants.\n\u003e\u003e\n\u003e\u003e CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to\n\u003e\u003e implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still\n\u003e\u003e useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for\n\u003e\u003e a potential vault user.\n\u003e\u003e\n\u003e\u003e If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain\n\u003e\u003e usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In\n\u003e\u003e the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind\n\u003e\u003e statechains, etc..[1]).\n\u003e\u003e\n\u003e\u003e Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that\n\u003e\u003e BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.\n\u003e\u003e Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables\n\u003e\u003e CTV's features, for the same reason they'd oppose BIP119.\n\u003e\u003e\n\u003e\u003e [0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also\n\u003e\u003e `sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.\n\u003e\u003e\n\u003e\u003e [1] https://anyprevout.xyz/ \"Use Cases\" section\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/0c24b9fb/attachment-0001.html\u003e",
"sig": "44ace8697135702f4710d213dbf0161b7872f9b862e01c20e3fe53b01699111c9dd33c2d6a0766beaffbd8ed19b1d1b2b497efc61c3a9efb91eb28fe73c5b30d"
}