Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-23 📝 Original message:Still trying to make sure ...
📅 Original date posted:2022-04-23
📝 Original message: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 :)
📝 Original message: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 :)