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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6843A71
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Aug 2016 11:13:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com
[209.85.220.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70C9A16B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Aug 2016 11:13:54 +0000 (UTC)
Received: by mail-qk0-f196.google.com with SMTP id q62so25391833qkf.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 06 Aug 2016 04:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=gnBcCkLS3vyFkO3sjGGpf+Ba5C9RrV9sZ9VyYX4E7EU=;
b=vCGPnON3kuXbrUVeaCTK0o+OoxH7in/Tz909XyFzFNo2wupZKTtPR56IKzYq+kaan8
j4ZR3oEX2R/N3/Snxtk6yxhPty9qKlkp06/XZxcfjGPVVZHIt5o4hpKARpPnqs9EWW5k
eVXPE0SRnu0rIzL+iNuHAs+MNWd45yzuAn8OZGpSPYM0RgGsWkW8tqhLi9CU6GSUXPQv
Km+5iSw70jyEdzKVRGTfKOWrOSqMlBGiCiBNFVQLP+2ysFCNBH3aaWG5+dq2+FjBBD+S
J/Q7srN0PbhpINfNsb4IJ7riha+XUC2pddT2Wo7gQbPdTONu7bcwy+4LDPyENy5NK4Ke
CwOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=gnBcCkLS3vyFkO3sjGGpf+Ba5C9RrV9sZ9VyYX4E7EU=;
b=eE9Po8ANCXlYogVrC8nqTKO1KsU6GV8sflotP+wXHTiAaYKJZ7jLQmnraKcUN21Wax
D8Hd/hjxp9FqqxCg6q6pu0xVQcS0ZX6W06N16Tat684Lc/0cS/lCS5mbZ0ukEGMX0A5E
+AyDbUPyV/Y/y0TgQXhk3kJm7Op0ZyepkCdt3ZNeJDkGOx/8P83O2gtXgB3pFLnFz5qM
rylFJIFg2Zl/GRrx89zLJ//em5TOqMkAJQm3eN43mXJeSEy6oCmBUSafhtSH2hsmzzhd
IThuAdmAet2X3uHE0M5HCxX9b8m89YNNMiEGZCwArYOM/IB4ieYScdH3k4VtWuSkvr7x
xXSA==
X-Gm-Message-State: AEkoout5PmYXs+HPgrLskUAO+RszkVvEw7Lrl8UxBmQaUNAPVsr4RcAROcWX2kdRSlESQcgEkd+GiDQ6c96p1Q==
X-Received: by 10.55.1.202 with SMTP id u71mr16549623qkg.195.1470482033395;
Sat, 06 Aug 2016 04:13:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.193 with HTTP; Sat, 6 Aug 2016 04:13:52 -0700 (PDT)
In-Reply-To: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sat, 6 Aug 2016 12:13:52 +0100
Message-ID: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114588d43fcc9f053965478f
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
Subject: Re: [bitcoin-dev] BIP clearing house addresses
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: Sat, 06 Aug 2016 11:13:55 -0000
--001a114588d43fcc9f053965478f
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> * reversal of transactions is impossible
>
I think it would be more accurate to say that the requirement is that
reversal doesn't happen unexpectedly.
If it is clear in the script that reversal is possible, then obviously the
recipient can take that into consideration.
> * keep private keys private and safe. Lose them, it's like losing cash,
> you can just forget about it.
>
Key management is a thing. Managing risk by keeping some keys offline is
an important part of that.
> * while we try hard to make 0-conf as safe as possible (if there's no
> RBF flag on the transaction), we make it almost impossible or very very
> expensive to reverse a confirmed transaction.
>
BitGo has an "instant" system where they promise to only sign one
transaction for a given output. If you trust BitGo, then this is safe from
double spending, since a double spender can't sign two transactions.
If BitGo had actually implemented a daily withdrawal limit, then their
system ends up similar to cold storage. Only 10% of the funds at Bitfinex
could have been withdrawn before manual intervention was required (with
offline keys).
Who will accept
> such an input and treat it as a payment if it can be reversed during the
> settlement layer?
Obviously, if a payment is reversible, then you treat it as a reversible
payment. The protection here relates to moving coins from the equivalent
of cold storage to hot storage.
It is OK if it takes longer, since security is more important than
convenience for coins in cold storage.
> The linked page describes that merchants will never accept payments from
> 'vaults', and it will take 24 hours for coins to be irreversible moved
> outside the 'vault'.
This relates to the reserves held by the exchange. A portion of the funds
are in hot storage with live keys. These funds can be stolen by anyone who
gets access to the servers. The remaining funds are held in cold storage
and they cannot be accessed unless you have the offline keys. These funds
are supposed to be hard to reach and require manual intervention.
I think this is a wrong approach. hacks and big losses are sad, but all
> the time users / exchanges are to blame for wrong implementations or
> terrible security practices.
>
Setting up offline keys to act as firebreaks is part of good security
practices.
--001a114588d43fcc9f053965478f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
* reversal of transactions is impossible<br></blockquote><div><br></div><di=
v>I think it would be more accurate to say that the requirement is that rev=
ersal doesn't happen unexpectedly.=C2=A0 <br><br>If it is clear in the =
script that reversal is possible, then obviously the recipient can take tha=
t into consideration.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
* keep private keys private and safe. Lose them, it's like losing cash,=
<br>
you can just forget about it.<br></blockquote><div><br></div><div>Key manag=
ement is a thing.=C2=A0 Managing risk by keeping some keys offline is an im=
portant part of that.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
* while we try hard to make 0-conf as safe as possible (if there's no<b=
r>
RBF flag on the transaction), we make it almost impossible or very very<br>
expensive to reverse a confirmed transaction.<br></blockquote><div><br></di=
v>BitGo has an "instant" system where they promise to only sign o=
ne transaction for a given output.=C2=A0 If you trust BitGo, then this is s=
afe from double spending, since a double spender can't sign two transac=
tions.<br><br></div><div class=3D"gmail_quote">If BitGo had actually implem=
ented a daily withdrawal limit, then their system ends up similar to cold s=
torage.=C2=A0 Only 10% of the funds at Bitfinex could have been withdrawn b=
efore manual intervention was required (with offline keys).<br><br></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Who will accept<br>
such an input and treat it as a payment if it can be reversed during the<br=
>
settlement layer? </blockquote><div><br></div><div>Obviously, if a payment =
is reversible, then you treat it as a reversible payment.=C2=A0 The protect=
ion here relates to moving coins from the equivalent of cold storage to hot=
storage.=C2=A0 <br><br>It is OK if it takes longer, since security is more=
important than convenience for coins in cold storage.<br></div><div>=C2=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
The linked page describes that merchants will never accept payments from<br=
>
'vaults', and it will take 24 hours for coins to be irreversible mo=
ved<br>
outside the 'vault'.</blockquote><div><br></div><div>This relates t=
o the reserves held by the exchange.=C2=A0 A portion of the funds are in ho=
t storage with live keys.=C2=A0 These funds can be stolen by anyone who get=
s access to the servers.=C2=A0 The remaining funds are held in cold storage=
and they cannot be accessed unless you have the offline keys.=C2=A0 These =
funds are supposed to be hard to reach and require manual intervention.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
I think this is a wrong approach. hacks and big losses are sad, but all<br>
the time users / exchanges are to blame for wrong implementations or<br>
terrible security practices.<br></blockquote><div><br></div><div>Setting up=
offline keys to act as firebreaks is part of good security practices.<br><=
/div></div></div></div>
--001a114588d43fcc9f053965478f--
|
