summaryrefslogtreecommitdiff
path: root/d6/23be1e3e7c4bbfe6b75ebd844ba4346ffa5397
blob: 31b918ac0fe59bc792dac4119333faf8ff0f299a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
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--