public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bryan Bishop <kanzure@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail•com>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
Date: Wed, 7 Aug 2019 15:32:47 -0500	[thread overview]
Message-ID: <CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com> (raw)
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>

Hi,

One of the biggest problems with the vault scheme (besides all of the
setup data that has to be stored for a long time) is an attacker that
silently steals the hot wallet private key and waits for the vault's
owner to make a delayed-spend transaction to initiate a withdrawal
from the vault. If the user was unaware of the theft of the key, then
the attacker could steal the funds after the delay period.

To mitigate this, it is important to choose a stipend or withdrawal
amount per withdrawal period like x% of the funds. This limits the
total stolen funds to x% because once the funds are stolen the user
would know their hot key is compromised, and the user would know to
instead use one of the other clawback paths during all of the future
withdrawal delay periods instead of letting the delay timeout all the
way to the (stolen) default/hot key.

The reason why a loss limiter is the way to go is because there's
currently no way (that I am aware of, without an upgrade) to force an
attacker to reveal his key on the blockchain while also forcing the
attacker to use a timelock before the key can spend the coins. I am
curious about what the smallest least invasive soft-fork would be for
enabling this kind of timelock. There are so many covenant proposals
at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
....). Or there's crazy things like a fork that enables a transaction
mode where the (timelock...) script of the first output is
automatically prefixed to any of the other scripts on any of the other
outputs when an input tries to spend in the future. A thief could add
his key to a new output on the transaction and try to spend (just like
a user would with a fresh/rotated key), but the OP_CSV would be
automatically added to his script to implement the public observation
delay window.

Also, there was other previous work that I was only informed about
today after posting my proposal, so I should mention these as related
work:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
https://www.youtube.com/watch?v=diNxp3ZTquo
https://bitcointalk.org/index.php?topic=5111656

- Bryan
http://heybryan.org/


  reply	other threads:[~2019-08-07 20:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 13:48 Bryan Bishop
2019-08-07 20:32 ` Bryan Bishop [this message]
2019-08-07 21:19   ` Dustin Dettmer
2019-08-08  2:09     ` Sergio Demian Lerner
2019-08-08  3:03       ` ZmnSCPxj
2019-08-08  0:27 ` ZmnSCPxj
2019-08-08  1:16   ` Bryan Bishop
2019-08-12 14:40 ` [bitcoin-dev] Single-use-Seal Implementation Peter Todd
2019-08-12 15:01 ` [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms Peter Todd
2019-08-13  2:09   ` Bryan Bishop
2019-08-13 14:15     ` Peter Todd
2019-08-13  2:44 ` Praveen Baratam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com \
    --to=kanzure@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox