MIME-Version: 1.0
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
	<CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com>
In-Reply-To: <CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Wed, 7 Aug 2019 14:19:05 -0700
Message-ID: <CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000064efe2058f8d7e2f"
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
	mechanisms
Precedence: list

--00000000000064efe2058f8d7e2f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Does revaulting vault up with the same keys, or new ones?

Are they new derivation paths on the same key?

Would love some expanded explanation on how you=E2=80=99re proposing this w=
ould
work.

Thanks,
Dustin

On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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/015=
793.html
>
> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-bet=
ter
> https://www.youtube.com/watch?v=3DdiNxp3ZTquo
> https://bitcointalk.org/index.php?topic=3D5111656
>
> - Bryan
> http://heybryan.org/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000064efe2058f8d7e2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Does revaulting vault up with the same keys, or new =
ones?</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Are they new=
 derivation paths on the same key?</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Would love some expanded explanation on how you=E2=80=99re propo=
sing this would work.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
anks,</div><div dir=3D"auto">Dustin</div><div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 7, 2019 at 1:35 PM Brya=
n Bishop via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Hi,<br>
<br>
One of the biggest problems with the vault scheme (besides all of the<br>
setup data that has to be stored for a long time) is an attacker that<br>
silently steals the hot wallet private key and waits for the vault&#39;s<br=
>
owner to make a delayed-spend transaction to initiate a withdrawal<br>
from the vault. If the user was unaware of the theft of the key, then<br>
the attacker could steal the funds after the delay period.<br>
<br>
To mitigate this, it is important to choose a stipend or withdrawal<br>
amount per withdrawal period like x% of the funds. This limits the<br>
total stolen funds to x% because once the funds are stolen the user<br>
would know their hot key is compromised, and the user would know to<br>
instead use one of the other clawback paths during all of the future<br>
withdrawal delay periods instead of letting the delay timeout all the<br>
way to the (stolen) default/hot key.<br>
<br>
The reason why a loss limiter is the way to go is because there&#39;s<br>
currently no way (that I am aware of, without an upgrade) to force an<br>
attacker to reveal his key on the blockchain while also forcing the<br>
attacker to use a timelock before the key can spend the coins. I am<br>
curious about what the smallest least invasive soft-fork would be for<br>
enabling this kind of timelock. There are so many covenant proposals<br>
at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,<br>
....). Or there&#39;s crazy things like a fork that enables a transaction<b=
r>
mode where the (timelock...) script of the first output is<br>
automatically prefixed to any of the other scripts on any of the other<br>
outputs when an input tries to spend in the future. A thief could add<br>
his key to a new output on the transaction and try to spend (just like<br>
a user would with a fresh/rotated key), but the OP_CSV would be<br>
automatically added to his script to implement the public observation<br>
delay window.<br>
<br>
Also, there was other previous work that I was only informed about<br>
today after posting my proposal, so I should mention these as related<br>
work:<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Feb=
ruary/015793.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2018-February/015793.html</a><br>
<a href=3D"https://blog.oleganza.com/post/163955782228/how-segwit-makes-sec=
urity-better" rel=3D"noreferrer" target=3D"_blank">https://blog.oleganza.co=
m/post/163955782228/how-segwit-makes-security-better</a><br>
<a href=3D"https://www.youtube.com/watch?v=3DdiNxp3ZTquo" rel=3D"noreferrer=
" target=3D"_blank">https://www.youtube.com/watch?v=3DdiNxp3ZTquo</a><br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D5111656" rel=3D"norefe=
rrer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D5111656</=
a><br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--00000000000064efe2058f8d7e2f--