📅 Original date posted:2022-04-23
📝 Original message:Okay, Matt explained to me the intended application of CTV vaults off list,
so I have a better understanding now.
The CTV vault scheme is designed as an improvement over the traditional
management of hot-wallets and cold-wallets. The CTV vault is logically on
the "cold-side" and lets funds be sent from the "cold" side to *one's own*
the hot wallet after the unvaulting delay. In this case, the hot wallet
funds are always at risk, so it isn't unexpected that those funds could be
stolen. After all, that is how hot wallets are today. The advantage is
that funds can be moved from the "cold" side without needing to dig out the
cold keys.
The MES vault scheme applies to a different scenario. In the MES case it
is the hot funds are inside the vault, and it is the hot key that unvaults
the funds and sends them to *customer's addresses* after a delay. If the
hot-key is used in any unauthorised way, then funds can be sent to the
address of the cold key (the MES vault actually does something fancy in
case of recovery, but it could be adapted to simply send funds to a cold
wallet).
The MES vault lie somewhere between "better" and "different" when compared
to the CTV vault. If one is unwilling to use the MES vault on the hot side
and have every withdrawl vetted, then, while you could use the MES design
on the cold side like the CTV vault, it wouldn't really offer you any
advantages over a CTV vault. However, if you are interested in managing
all your payments through a vault (as I've been imagining) then the CTV
vault comes across as ineffective when compared to an MES style vault.
On Sat, Apr 23, 2022 at 2:24 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Still trying to make sure I understand this concern, let me know if I get
> this all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > It's not the attackers *only choice to succeed*. If an attacker steals
> the hot key, then they have
> > the option to simply wait for the user to unvault their funds of their
> own accord and then race /
> > outspend the users transaction with their own. Indeed, this is what we
> expect would happen in the
> > dark forest.
>
> Right, a key security assumption of the CTV-based vaults would be that you
> MUST NOT EVER withdraw
> more in one go than your hot wallet risk tolerance, but given that your
> attack isn't any worse than
> simply stealing the hot wallet key immediately after a withdraw.
>
> It does have the drawback that if you ever get a hot wallet key stole you
> have to rotate all of your
> CTV outputs and your CTV outputs must never be any larger than your hot
> wallet risk tolerance
> amount, both of which are somewhat frustrating limitations, but not
> security limitations, only
> practical ones.
>
> > And that's not even mentioning the issues already noted by the document
> regarding fee management,
> > which would likely also benefit from a less constrained design for
> covenants.
>
> Of course I've always been in favor of a less constrained covenants design
> from day one for ten
> reasons, but that's a whole other rabbit hole :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/8077c9f2/attachment-0001.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 23:07:44
in reply to nevent1q…gjsf
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 23:07:44Event JSON
{
"id": "ffcc540afd5afd558bfeb09d9e3d9d51505130b37179f81b67f7b315d6cc00e5",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686179264,
"kind": 1,
"tags": [
[
"e",
"8ed1c5df2d8c4c17d986e3cbb63145cfb9cb56b890067e0e4f01c91fe94d991b",
"",
"root"
],
[
"e",
"5d1f91f5bad9fc7c5f123ecdc9271b537780c3c542bd04ab44469c59ba0eec7f",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2022-04-23\n📝 Original message:Okay, Matt explained to me the intended application of CTV vaults off list,\nso I have a better understanding now.\n\nThe CTV vault scheme is designed as an improvement over the traditional\nmanagement of hot-wallets and cold-wallets. The CTV vault is logically on\nthe \"cold-side\" and lets funds be sent from the \"cold\" side to *one's own*\nthe hot wallet after the unvaulting delay. In this case, the hot wallet\nfunds are always at risk, so it isn't unexpected that those funds could be\nstolen. After all, that is how hot wallets are today. The advantage is\nthat funds can be moved from the \"cold\" side without needing to dig out the\ncold keys.\n\nThe MES vault scheme applies to a different scenario. In the MES case it\nis the hot funds are inside the vault, and it is the hot key that unvaults\nthe funds and sends them to *customer's addresses* after a delay. If the\nhot-key is used in any unauthorised way, then funds can be sent to the\naddress of the cold key (the MES vault actually does something fancy in\ncase of recovery, but it could be adapted to simply send funds to a cold\nwallet).\n\nThe MES vault lie somewhere between \"better\" and \"different\" when compared\nto the CTV vault. If one is unwilling to use the MES vault on the hot side\nand have every withdrawl vetted, then, while you could use the MES design\non the cold side like the CTV vault, it wouldn't really offer you any\nadvantages over a CTV vault. However, if you are interested in managing\nall your payments through a vault (as I've been imagining) then the CTV\nvault comes across as ineffective when compared to an MES style vault.\n\nOn Sat, Apr 23, 2022 at 2:24 PM Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e Still trying to make sure I understand this concern, let me know if I get\n\u003e this all wrong.\n\u003e\n\u003e On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:\n\u003e \u003e It's not the attackers *only choice to succeed*. If an attacker steals\n\u003e the hot key, then they have\n\u003e \u003e the option to simply wait for the user to unvault their funds of their\n\u003e own accord and then race /\n\u003e \u003e outspend the users transaction with their own. Indeed, this is what we\n\u003e expect would happen in the\n\u003e \u003e dark forest.\n\u003e\n\u003e Right, a key security assumption of the CTV-based vaults would be that you\n\u003e MUST NOT EVER withdraw\n\u003e more in one go than your hot wallet risk tolerance, but given that your\n\u003e attack isn't any worse than\n\u003e simply stealing the hot wallet key immediately after a withdraw.\n\u003e\n\u003e It does have the drawback that if you ever get a hot wallet key stole you\n\u003e have to rotate all of your\n\u003e CTV outputs and your CTV outputs must never be any larger than your hot\n\u003e wallet risk tolerance\n\u003e amount, both of which are somewhat frustrating limitations, but not\n\u003e security limitations, only\n\u003e practical ones.\n\u003e\n\u003e \u003e And that's not even mentioning the issues already noted by the document\n\u003e regarding fee management,\n\u003e \u003e which would likely also benefit from a less constrained design for\n\u003e covenants.\n\u003e\n\u003e Of course I've always been in favor of a less constrained covenants design\n\u003e from day one for ten\n\u003e reasons, but that's a whole other rabbit hole :)\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/8077c9f2/attachment-0001.html\u003e",
"sig": "81b854a9f461e8e964126bc47e87a9d253bc3d8337727a991700282e8cce599ce37ed9f68a61062657e99f6be47db1f3619699e385edc982c26de771cefa87a9"
}