path: root/0e/1cf3ac0090585d3b6470cc06159e2cceb28a29

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 21AE4CC4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Aug 2019 02:10:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com
	[209.85.208.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12544829
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Aug 2019 02:09:59 +0000 (UTC)
Received: by mail-lj1-f172.google.com with SMTP id h10so15870940ljg.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 07 Aug 2019 19:09:58 -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
	:cc; bh=fCpOxnUupu8GoN4sIxf9uutOAf7HgiYYOw5kk1Dwj3s=;
	b=Gt8rOXfw5+lHKje77T1pvjyVnDmmuLroO3djOMj244pEW8IN9Nwezm09v+Xik2LElJ
	96FZtix73GR2syVi4wD5tXdbbQI2RyEYmI2R/TZksJrqfiREhx7LigAg34HneF4Syfvk
	Q+Ty8kXHH5Ey9tx5sm1PE9JUFJjnmJctOXhuXrOnaHLwIdoMGlwG5KvzIKIMLZHH4tgg
	E9Gg/6dkreG4KoY78kRwbIU/KlkV/kVGtF7KiPSNZu1uSsMHajyN3j6R3wfbLBe+fC4m
	njCbi1Dcxz19L+dVP+adLgcFKrT7CDCYaFcal0tcCPHyi0rjeXLDcn72vD9DNHYMUn44
	6mww==
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:cc;
	bh=fCpOxnUupu8GoN4sIxf9uutOAf7HgiYYOw5kk1Dwj3s=;
	b=LhEqpbZmQ7BsR64RyqIdBfIm4BeXxl1YD5FGc01uej4SNih3Pb+o01ZFWsNW1yHr+Y
	Jr+uoav97ubzq/YWKJtye8lYuryEEiJzlJ4E62ROxitzpZTxc08ZzJCeKTLpU9zjoLtc
	0RHlhnKiqsHJsL3pSZ8Uuk9rpVVtIY7cdKePP+qd5paftdxCQCxdlvrEHh07matugmRt
	UMnHukEApKkPp7W/XwTm1ZrvjjEwOX7bm0O3cqtkFFjALIMBh7EdrGt6t/35jyzfyo3C
	6fCuaSs3+lpA2/tyZ0J3XlXrA3xJPonC+XkQ5Bh9tI4z90LdqVxj4okNbxGMJrFHMkjU
	v6Jw==
X-Gm-Message-State: APjAAAUo9SxXdgoW3eYY/4ZNNvcEXICbhORbHDu9lTZZLCNcBmY2PNkp
	HmUQbgfoXpR8kJKVr12O+T/M7wqUVNCbVEMI9GA=
X-Google-Smtp-Source: APXvYqxwD0wlI5XzAZVAOOWeVEsG/IW5KNOk2d+M4xGqz5H+E12y40oFk5KMZL9jtZE920pQmaoSWTQcjZcT0DO5wp8=
X-Received: by 2002:a2e:9dca:: with SMTP id x10mr6408395ljj.17.1565230197316; 
	Wed, 07 Aug 2019 19:09:57 -0700 (PDT)
MIME-Version: 1.0
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
	<CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com>
	<CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com>
In-Reply-To: <CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Wed, 7 Aug 2019 23:09:20 -0300
Message-ID: <CAKzdR-q3nnWggUz7aE0p1ts8KsWVigznjuJpR1SNzKNXs+GmiA@mail.gmail.com>
To: Dustin Dettmer <dustinpaystaxes@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e71f3f058f918d04"
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: Thu, 08 Aug 2019 02:14:03 +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: Thu, 08 Aug 2019 02:10:00 -0000

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

Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=3D307211.msg3308565#msg3308565

However I remember that someone told me the tick method had a flaw..



On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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=
 would
> 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/01=
5793.html
>>
>> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-be=
tter
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Seems to be comparable to the proposed &quot;Tick Method&q=
uot; from 2013:<div><a href=3D"https://bitcointalk.org/index.php?topic=3D30=
7211.msg3308565#msg3308565">https://bitcointalk.org/index.php?topic=3D30721=
1.msg3308565#msg3308565</a>=C2=A0</div><div><br></div><div>However I rememb=
er that someone told me the tick method had a flaw..</div><div>=C2=A0<br></=
div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div><div dir=3D"auto">Does revaulting vault u=
p 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 d=
ir=3D"auto"><br></div><div dir=3D"auto">Would love some expanded explanatio=
n on how you=E2=80=99re proposing this would work.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Thanks,</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 Bryan Bishop via bitcoin-dev &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);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>
_______________________________________________<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>

--000000000000e71f3f058f918d04--