path: root/d6/23be1e3e7c4bbfe6b75ebd844ba4346ffa5397

Return-Path: <dustinpaystaxes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EEEB5E92
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Aug 2019 21:19:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com
	[209.85.210.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B8A9823
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  7 Aug 2019 21:19:18 +0000 (UTC)
Received: by mail-ot1-f46.google.com with SMTP id r6so110079516oti.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 07 Aug 2019 14:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=YdG4gF5HBMcLoojALeSy258/fLn5TE49zaVXVY3ADSk=;
	b=pF/EvnKC3nDWoGwc5+g8ssnIJpg4xL9oowfW8ELOSvZeIdvLI/d5jyjjMI7KYaLfdy
	6gF3hjnR5K/thr7a720TXD/DwSaz++VLYXkKx96Q2Bi+TdsfghZmbkT9QJO1JryrODJm
	/x64vCogfxI9RCvqHn4Hdr/UskCOQNk3mRF21VRHeECit3pS5Iwz3UOx/odipc9D+Wdv
	ctFq+WglM/wCiQPWg9ZwulsdI0Ex0QW3zlNWYNjnlm21mJMsUp/I0CAwgeAGXkRh168s
	frZfDnX7KEGMnwOhtU05DoXEL9p4w/E/67vlj1PAXeCyGhc3VvhS/d3oqF+XctDGER+W
	5thQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=YdG4gF5HBMcLoojALeSy258/fLn5TE49zaVXVY3ADSk=;
	b=JO4Zz7+oGp91MNwSnNu9L7hqSu+S+uPwI3DvTzXYG5SF0grUCPIjcJm0gqe4GNLcrp
	UKbX0Zl+0y8fZWnGTnKRYHIMdtB5YmBYOS4VgT5nH9xUCff90/VM/K4TeXMf33AJFnmy
	JWkjFtVFJ2GLGRRxUz0JHCveEtCivX4abOMI8SRMMhDijg0HssKRSeYRvkJXXoqLifd6
	nHOvDh7C3vLqlKfDWDt8p/nLHVil3giMCakVnSSTNQ4g9zjWpv9W5vqVm65kPDNtEnpg
	0zGj15g+flqZ62qYKbjPW9RWlDt15ZK9haAKo4P7I9OQnBe5TO2Zvc2Iih332XXzuawE
	UnWg==
X-Gm-Message-State: APjAAAWVEAGEqN3Tasj5+A3zU0EMDEx7BCKboh4PMxYs1nbJAN+BBpn0
	mRLFZ5gS+x5OEPqnuCOTc0z9uldT6jOwix8gtE4HvQ==
X-Google-Smtp-Source: APXvYqymVJk4RTzxGK/TCXm2Whn3l+gpgtioOAHPLhKfJuBwObIZxvIUdy032u2KVbC2YSHGJ2h8S9SuQehzJzo27fw=
X-Received: by 2002:a6b:4f0d:: with SMTP id d13mr12062898iob.170.1565212757256;
	Wed, 07 Aug 2019 14:19:17 -0700 (PDT)
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"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 07 Aug 2019 21:27:37 +0000
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
	mechanisms
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 21:19:19 -0000

--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--