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
|
Return-Path: <el33th4x0r@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8019DD11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Feb 2016 16:05:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2C7A1A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Feb 2016 16:05:40 +0000 (UTC)
Received: by mail-wm0-f45.google.com with SMTP id g62so78385781wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Feb 2016 08:05:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:cc;
bh=EIcocvHLhnSjvdbm093NKi1z03Xyq4KSgsv6M7IvTNE=;
b=K+3feFFtt8rYvkxZapF+KnUhOVod2IGtecUnOef8YvUXQODwTunJ3C0iB2k7far2oN
UyoCAtsKOYYszJu7hlvtG9DvskBDgsK/OYqMMtmdJIhMazzd4iBlGa84yvf0Co5SKOrv
ITG2ZPNo4f8DPBfKQHh+ZC8Lr36MdlF2SHGV74kiolDVwgxST3EcTDtX+evBDEfYBvRf
0miltBgLnxufgMyCWo6QXyRM1p1SY/ETGrIowrW3SDaW7N+C5V5O8PF/Sjc3/9XkkT3x
NM7OU7Hat8RMyx4ED+VGza8bjqAh6DfcB6iwBGZG+c8domuMlkzrkSoGv2CjlfN4USZu
QQOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
bh=EIcocvHLhnSjvdbm093NKi1z03Xyq4KSgsv6M7IvTNE=;
b=bpBuuoeWFRnsmdjcx+sqIm0y0UGAttJO5cu0eAXRTTfMU6TgEIFwODKY5kqTX+aoYF
fVKBWYK0yAWSMC8Lfo37lUK6/HsBQPWUPsgps4rfIV+SRTshXAchEdIJHla73SNYmh8m
vgPbUWxvnEQ4RMjksJQJ4vNu2YmSgc9w3Kx2stvWYVO6NN0uBs6RlEXiqHGG66CcHdok
y4YdjbG09fIuRHGDm0DVrfq8LohwNT5Z1eriFzb84qkmZrKurgdvhCtGRBklnF+f/RwU
JsPYLVXwOguw/5ISU/Na1dSfDJDzF3pP0HCeEP0yItTT4Rte9mpQKsFVSWFnDMWTGMta
4eYA==
X-Gm-Message-State: AD7BkJIKITL5VuN2IcqjGonpxcQXR/llf6RclV04G1bk1PLTcigRUMXtos5TyaqUEjooOqAYyyxjKgSMOFJxhw==
X-Received: by 10.28.182.136 with SMTP id g130mr4042509wmf.10.1456502739613;
Fri, 26 Feb 2016 08:05:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.236.66 with HTTP; Fri, 26 Feb 2016 08:05:20 -0800 (PST)
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Fri, 26 Feb 2016 11:05:20 -0500
Message-ID: <CAPkFh0vuLsoNQUEdH-kGqXYvFJt1tXLvt0eMEuFZGm7Pus-_2g@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114b14e068c8a7052cae780e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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: Fri, 26 Feb 2016 16:06:17 +0000
Cc: =?UTF-8?B?TWFsdGUgTcO2c2Vy?= <malte.moeser@uni-muenster.de>,
Ittay Eyal <ittay.eyal@cornell.edu>
Subject: [bitcoin-dev] Bitcoin Vaults.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 26 Feb 2016 16:05:42 -0000
--001a114b14e068c8a7052cae780e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
At the 3rd Bitcoin Workshop being held in conjunction with the Financial
Cryptography Conference in Barbados, my group will be presenting a new idea
for improving Bitcoin wallet security and deterring thefts today.
The write-up is here:
http://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-va=
ults/
The paper with the nitty gritty details is here:
http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
The core idea:
Our paper describes a way to create vaults, special accounts whose keys can
be neutralized if they fall into the hands of attackers. Vaults are
Bitcoin=E2=80=99s decentralized version of you calling your bank to report =
a stolen
credit card -- it renders the attacker=E2=80=99s transactions null and void=
. And
here=E2=80=99s the interesting part: in so doing, vaults demotivate key the=
ft in
the first place. An attacker who knows that he will not be able to get away
with theft is less likely to attack in the first place, compared to current
Bitcoin attackers who are guaranteed that their hacking efforts will be
handsomely rewarded.
Operationally, the idea is simple. You send your money to a vault address
that you yourself create. Every vault address has a vault key and a
recovery key. When spending money from the vault address with the
corresponding vault key, you must wait for a predefined amount of time
(called the unvaulting period) that you established at the time you created
the vault -- say, 24 hours. When all goes well, your vault funds are
unlocked after the unvaulting period and you can move them to a standard
address and subsequently spend them in the usual way. Now, in case Harry
the Hacker gets a hold of your vault key, you have 24 hours to revert any
transaction issued by Harry, using the recovery key. His theft,
essentially, gets undone, and the funds are diverted unilaterally to their
rightful owner. It=E2=80=99s like an =E2=80=9Cundo=E2=80=9D facility that t=
he modern banking world
relies on, but for Bitcoin.
The technical trick relies on a single new opcode, CheckOutputVerify, that
checks the shape of a redeem transaction. Note that fungibility is not
affected, as the restrictions are at the discretion of the coin owner alone
and can only be placed by the coin owner ahead of time.
We suspect that this modest change could actually be a game-changer for
bitcoin security: clients and keys are notoriously hard to secure, and a
facility that allows you to possibly recover, and if not, permanently keep
the hacker from acquiring your funds, could greatly deter Bitcoin thefts.
As always, comments and suggestions are welcome.
- egs, Ittay Eyal and Malte Moeser.
--001a114b14e068c8a7052cae780e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">At the 3rd Bitcoin Workshop being held in conjunction with=
the Financial Cryptography Conference in Barbados, my group will be presen=
ting a new idea for improving Bitcoin wallet security and deterring thefts =
today.=C2=A0<div><br></div><div>The write-up is here:</div><div>=C2=A0 =C2=
=A0=C2=A0<a href=3D"http://hackingdistributed.com/2016/02/26/how-to-impleme=
nt-secure-bitcoin-vaults/">http://hackingdistributed.com/2016/02/26/how-to-=
implement-secure-bitcoin-vaults/</a></div><div><br></div><div>The paper wit=
h the nitty gritty details is here:</div><div>=C2=A0 =C2=A0=C2=A0<a href=3D=
"http://fc16.ifca.ai/bitcoin/papers/MES16.pdf">http://fc16.ifca.ai/bitcoin/=
papers/MES16.pdf</a></div><div><br></div><div>The core idea:<br><div><br></=
div><div><div>Our paper describes a way to create vaults, special accounts =
whose keys can be neutralized if they fall into the hands of attackers. Vau=
lts are Bitcoin=E2=80=99s decentralized version of you calling your bank to=
report a stolen credit card -- it renders the attacker=E2=80=99s transacti=
ons null and void. And here=E2=80=99s the interesting part: in so doing, va=
ults demotivate key theft in the first place. An attacker who knows that he=
will not be able to get away with theft is less likely to attack in the fi=
rst place, compared to current Bitcoin attackers who are guaranteed that th=
eir hacking efforts will be handsomely rewarded.</div><div><br></div><div>O=
perationally, the idea is simple. You send your money to a vault address th=
at you yourself create. Every vault address has a vault key and a recovery =
key. When spending money from the vault address with the corresponding vaul=
t key, you must wait for a predefined amount of time (called the unvaulting=
period) that you established at the time you created the vault -- say, 24 =
hours. When all goes well, your vault funds are unlocked after the unvaulti=
ng period and you can move them to a standard address and subsequently spen=
d them in the usual way. Now, in case Harry the Hacker gets a hold of your =
vault key, you have 24 hours to revert any transaction issued by Harry, usi=
ng the recovery key. His theft, essentially, gets undone, and the funds are=
diverted unilaterally to their rightful owner. It=E2=80=99s like an =E2=80=
=9Cundo=E2=80=9D facility that the modern banking world relies on, but for =
Bitcoin.</div><div><br></div></div></div><div>The technical trick relies on=
a single new opcode, CheckOutputVerify, that checks the shape of a redeem =
transaction. Note that fungibility is not affected, as the restrictions are=
at the discretion of the coin owner alone and can only be placed by the co=
in owner ahead of time.=C2=A0</div><div><br></div><div>We suspect that this=
modest change could actually be a game-changer for bitcoin security: clien=
ts and keys are notoriously hard to secure, and a facility that allows you =
to possibly recover, and if not, permanently keep the hacker from acquiring=
your funds, could greatly deter Bitcoin thefts.=C2=A0</div><div><br></div>=
<div>As always, comments and suggestions are welcome.</div><div>- egs, Itta=
y Eyal and Malte Moeser.</div><div><br></div></div>
--001a114b14e068c8a7052cae780e--
|
