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
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 88D9D71
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Aug 2016 22:59:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
[209.85.161.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E996084
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Aug 2016 22:59:35 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id u134so295590904ywg.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Aug 2016 15:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=BCrHu6gmryFZbQP6J9HI9Ofc8VsbCQfwaCFexE+ew90=;
b=f0qVOlAEs5QiUbAzHjw0iHPUPYEbImLqrBjTN4J9fMWjK8yNYfbRHZwDcXd2/lDfxA
lexkDJZHjJGVqWK7MFY1LOdWzQ0s2mks47CTxxcesXBeb/J9o4W8fWYXdIByVyLg/W7e
6R4+0slc2C205ULlKwyRyREW1tPnqKxa/jT+BSE3gAqUr7Yp71jHLM5YS/lcJhI8/58m
5Awir7rZQCmVjJMMb3WRc9YgGkCCE8k5aSsj5GRGK+GFxpsupvT1+nNZr+sxfKFVFbYh
FENaOHiCcXi4CZ/lsDtbCpWvEQ8o56gdQqspcRd2wkEf6Pw7TbVTMKIvUx83evyylfVL
Z6xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=BCrHu6gmryFZbQP6J9HI9Ofc8VsbCQfwaCFexE+ew90=;
b=V1aZ2FtO97Y1P/xQdbK81kuShJboqW8vzyqEnW7wDDErtPP8Rj7u+I6sWVXNCzzyu1
ONb3pV6uZCKNB4p70425AWvNP0jhwOc6xuaYORCBZuxdvwOpIxmUxKXQEHzA7e4L7sRm
+M5BFlicqFVu4I+rtUHTG8wZ2ZGu5XlQoVOJLcdoDY8Mqv0cwH0TB1lZJzjf5QH3ahro
7bBWWAgXdQnZwRH+bUsT3bpB6bvN+cikBJJ7CHRvXsHFcg1r/Q7lCSIXct1zQxG8eR/f
xHLDtbe3zYn/tuZPyrXqqmtr4uRIl9Xi3P/DclNbHt74TSO6oNxxIg90Fo1S/E5/huQX
0bng==
X-Gm-Message-State: AEkooutZ/Rl5dkkOk0uQ4xcIo5C5c+0ZqyRcyf/hlFIPX9eWsHgbxeSnzFOdS6xv0zqbw3R5QRp1FJMjz7u42g==
X-Received: by 10.129.83.193 with SMTP id h184mr9404310ywb.52.1470610775068;
Sun, 07 Aug 2016 15:59:35 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.88.214 with HTTP; Sun, 7 Aug 2016 15:59:34 -0700 (PDT)
In-Reply-To: <CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sun, 7 Aug 2016 18:59:34 -0400
X-Google-Sender-Auth: Tp1Z9c3aTrSe4CgRSwNa51ggWeE
Message-ID: <CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
To: Matthew Roberts <matthew@roberts.pm>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114d6f1cd9dfd405398340f1
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
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: Sun, 07 Aug 2016 22:59:37 -0000
--001a114d6f1cd9dfd405398340f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I still feel like you're better off getting rid of "hot wallets" and use
lightning-esqe networks to route orders. I don't think either speed or
flexibility is an issue there.
IMO, the point of Bitcoin is to avoid the centralization that seems to be
happening on the network now. By making "hot wallets" more "secure", we
encourage things to keep heading downhill with massive centralized
crappy-security exchanges.
Because, ultimately, there's no security that will prevent an inside job.
And all of these thefts have, in my opinion, been at least partly inside
jobs.
And centralization is the actually demon that needs slaying here.
A client-side library with P2P order routing, tether.to + bitcoin .... and
you've got a decentralized exchange... with orders matched to users
directly, and channel-trades executed instantly. And "market makers"
running nodes to facilitate routing, etc.
No center... nothing to shut down or sue... and no one holds your funds.
That's a real Bitcoin exchange.
On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I'm wondering if we're fully on the same page here. What I was thinking
> was that this protection mechanism would be applied to the coins in the h=
ot
> wallet (I wasn't talking about moving coins from the cold wallet to the h=
ot
> wallet -- though such a mechanism is also needed.)
>
> With the hot wallet you would have an output script that only allowed
> coins to be sent to a new transaction whose output script was then only
> redeemable after N confirmations (the output is relative time-locked) but
> which can also be recovered to a fixed fail-safe address before the
> time-lock is reached (exactly like TierNolan already listed only the
> time-locked destination shouldn't be completely fixed.) So the private ke=
y
> for this hot wallet can still sign valid transactions to withdraw coins t=
o
> any known destination and these transactions still reach the blockchain.
>
> The key difference from a regular transaction is that the destination onl=
y
> has access to the coins -after- the relative time-lock is reached (N bloc=
ks
> after first confirm) so everyone knows where withdrawals are suppose to b=
e
> going and how many coins are being withdrawn at any given time. Deposits =
to
> the hot wallet would therefore need to be encumbered by the same protecti=
on
> so that from then on this time-lock to redeem coins can be applied to eve=
ry
> new transaction trying to move coins (withdrawn by a user of the exchange
> or sent to the cold wallet.)
>
> Notice we don't care about the destination in the TX script for the hot
> wallet because to process user's withdrawals we can't know ahead of time
> where they need to be sent (so it isn't possible to use a fixed address
> here =E2=80=93 though you might want to remove the clearing phase and set=
a fixed
> address for coins sent from the hot wallet to the cold wallet.) The benef=
it
> here comes from being able to see what withdrawals are being cleared,
> matching those up to our expectations, and being able to "cancel"
> withdrawals if they look suspicious, and you get the benefits for transfe=
rs
> made from the hot wallet to the cold wallet and visa-versa.
>
>
> This approach is good for a number of crucial services:
>
> 1. Wallets could be built that grouped coins into different "accounts"
> with different time-frames required for clearing / unlocking coins. Your
> savings or investment account would say -- take up to a week to clear --
> whereas your everyday account used for smaller purchases (with less money=
)
> would only take a few hours. This could all be linked up to services that
> notified you of your money being moved + made any phone calls needed to
> verify any larger transfers.
>
> The service could also be entrusted with the =E2=80=9Ccancellation=E2=80=
=9D key which can
> only be used to move money to your offline fail-safe address. This would =
be
> quite an interesting way to mitigate fraud without the user having to be
> trusted to do anything (except I suppose =E2=80=93 not storing their reco=
very keys
> online =E2=80=A6 but this could be partially solved with BIP 32-style =E2=
=80=9Cmaster=E2=80=9D
> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
>
> 2. Gambling websites that process a lot of Bitcoins also have a hot walle=
t
> which could be better protected by this.
>
> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
> web markets come to mind -- hey, people breaking the law need good securi=
ty
> too.)
>
> 4. Provable dead man's switches on the protocol level is another idea --
> no need to keep special time-locked transactions around and rely on them =
to
> be broadcast =3D more reliable escrow services.
>
> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
>
> I hope that makes sense. I think I initially managed to confuse a lot of
> people by talking about revoking transactions / =E2=80=9Csettlement layer=
s=E2=80=9D, etc.
> But IMO: all of this needs to take place on the blockchain with a new set
> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I thi=
nk
> the general idea would still work.
>
>
> tl; dr, A pseudo-reversal mechanism for transactions would mean that
> stolen private keys were no longer such an issue. This is desperately
> needed for exchanges, wallets, and other services that are forced to mana=
ge
> private keys, and whose users (I argue) already expect for this to be
> possible (or at least will when they're hacked.)
>
>
>
>
> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 i=
s
>> 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 f=
rom
>> 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 Bitfin=
ex
>> 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 th=
e
>>> 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 equivalen=
t
>> 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 fro=
m
>>> '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 key=
s.
>> 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.
>>
>> _______________________________________________
>> 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
>
>
--001a114d6f1cd9dfd405398340f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I still feel like you're better off getting rid o=
f "hot wallets" and use lightning-esqe networks to route orders.=
=C2=A0 I don't think either speed or flexibility is an issue there.=C2=
=A0=C2=A0 <br><br>IMO, the point of Bitcoin is to avoid the centralization =
that seems to be happening on the network now.=C2=A0=C2=A0 By making "=
hot wallets" more "secure", we encourage things to keep head=
ing downhill with massive centralized crappy-security exchanges.<br><br></d=
iv><div>Because, ultimately, there's no security that will prevent an i=
nside job.=C2=A0=C2=A0 And all of these thefts have, in my opinion, been at=
least partly inside jobs.<br><br></div><div>And centralization is the actu=
ally demon that needs slaying here.<br><br></div><div>A client-side library=
with P2P order routing, <a href=3D"http://tether.to">tether.to</a> + bitco=
in ....=C2=A0 and you've got a decentralized exchange... with orders ma=
tched to users directly, and channel-trades executed instantly.=C2=A0=C2=A0=
And "market makers" running nodes to facilitate routing, etc.<br=
><br></div><div>No center... nothing to shut down or sue... and no one hold=
s your funds.=C2=A0=C2=A0 That's a real Bitcoin exchange. <br></div><di=
v><br><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <span =
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<p style=3D"margin-bottom:0in">I'm wondering if we're fully on the
same page here. What I was thinking was that this protection
mechanism would be applied to the coins in the hot wallet (I wasn't
talking about moving coins from the cold wallet to the hot wallet --
though such a mechanism is also needed.)</p>
<p style=3D"margin-bottom:0in">With the hot wallet you would have an
output script that only allowed coins to be sent to a new transaction
whose output script was then only redeemable after N confirmations (the
output is relative time-locked) but which can also be recovered to a
fixed fail-safe address before the time-lock is reached (exactly like
TierNolan already listed only the time-locked destination shouldn't
be completely fixed.) So the private key for this hot wallet can still sign
valid transactions to withdraw coins to any known destination and
these transactions still reach the blockchain.</p>
<p style=3D"margin-bottom:0in">The key difference from a regular
transaction is that the destination only has access to the coins
-after- the relative time-lock is reached (N blocks after first
confirm) so everyone knows where withdrawals are suppose to be going
and how many coins are being withdrawn at any given time. Deposits to
the hot wallet would therefore need to be encumbered by the same
protection so that from then on this time-lock to redeem coins can be
applied to every new transaction trying to move coins (withdrawn by a
user of the exchange or sent to the cold wallet.)</p>
<p style=3D"margin-bottom:0in">Notice we don't care about the
destination in the TX script for the hot wallet because to process
user's withdrawals we can't know ahead of time where they need to b=
e
sent (so it isn't possible to use a fixed address here =E2=80=93 though=
you
might want to remove the clearing phase and set a fixed address for
coins sent from the hot wallet to the cold wallet.) The benefit here
comes from being able to see what withdrawals are being cleared,
matching those up to our expectations, and being able to "cancel"
withdrawals if they look suspicious, and you get the benefits for transfers=
made from the hot wallet to the cold wallet and visa-versa.<br></p>
<p style=3D"margin-bottom:0in"><br>
</p>
<p style=3D"margin-bottom:0in">This approach is good for a number of
crucial services:</p>
<p style=3D"margin-bottom:0in">1. Wallets could be built that grouped
coins into different "accounts" with different time-frames
required for clearing / unlocking coins. Your savings or investment
account would say -- take up to a week to clear -- whereas your
everyday account used for smaller purchases (with less money) would
only take a few hours. This could all be linked up to services that
notified you of your money being moved + made any phone calls needed
to verify any larger transfers.</p>
<p style=3D"margin-bottom:0in">The service could also be entrusted
with the =E2=80=9Ccancellation=E2=80=9D key which can only be used to move =
money
to your offline fail-safe address. This would be quite an interesting
way to mitigate fraud without the user having to be trusted to do
anything (except I suppose =E2=80=93 not storing their recovery keys online
=E2=80=A6 but this could be partially solved with BIP 32-style =E2=80=9Cmas=
ter=E2=80=9D
public keys + hardware wallets + multi-sig, N factor auth, etc ...)</p>
<p style=3D"margin-bottom:0in">2. Gambling websites that process a lot
of Bitcoins also have a hot wallet which could be better protected by
this.</p>
<p style=3D"margin-bottom:0in">3. Various other e-commerce websites
also accept Bitcoins directly. (Deep web markets come to mind -- hey,
people breaking the law need good security too.)</p>
<p style=3D"margin-bottom:0in">4. Provable dead man's switches on the
protocol level is another idea -- no need to keep special time-locked
transactions around and rely on them to be broadcast =3D more reliable
escrow services.</p>
<br>5. And obviously exchange hot (and
cold) wallets - enemy number 1.
<br><br>
<p style=3D"margin-bottom:0in">I hope that makes sense. I think I
initially managed to confuse a lot of people by talking about
revoking transactions / =E2=80=9Csettlement layers=E2=80=9D, etc. But IMO: =
all of
this needs to take place on the blockchain with a new set of OP_CODES
and other than the fixed address issue with OP_SPENDTO, I think the
general idea would still work.</p><p style=3D"margin-bottom:0in"><br></p>tl=
; dr, A pseudo-reversal mechanism for transactions would mean that stolen p=
rivate keys were no longer such an issue. This is desperately needed for ex=
changes, wallets, and other services that are forced to manage private keys=
, and whose users (I argue) already expect for this to be possible (or at l=
east will when they're hacked.)<br><p style=3D"margin-bottom:0in"><br>
</p>
<p style=3D"margin-bottom:0in"><br>
</p>
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div c=
lass=3D"h5">On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <spa=
n dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>=
wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><s=
pan>On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <span dir=3D"ltr">=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
* reversal of transactions is impossible<br></blockquote><div><br></div></s=
pan><div>I think it would be more accurate to say that the requirement is t=
hat reversal doesn't happen unexpectedly.=C2=A0 <br><br>If it is clear =
in the script that reversal is possible, then obviously the recipient can t=
ake that into consideration.<br></div><span><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
* 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></span><div>Ke=
y management is a thing.=C2=A0 Managing risk by keeping some keys offline i=
s an important part of that.<br></div><span><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
* 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></span>BitGo has an "instant" system where they promise to only=
sign one transaction for a given output.=C2=A0 If you trust BitGo, then th=
is is safe from double spending, since a double spender can't sign two =
transactions.<br><br></div><div class=3D"gmail_quote">If BitGo had actually=
implemented a daily withdrawal limit, then their system ends up similar to=
cold storage.=C2=A0 Only 10% of the funds at Bitfinex could have been with=
drawn before manual intervention was required (with offline keys).<br><br><=
/div><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Who wi=
ll 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></span><div>Obviously, if a p=
ayment is reversible, then you treat it as a reversible payment.=C2=A0 The =
protection 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><spa=
n><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-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></span><div>This re=
lates to the reserves held by the exchange.=C2=A0 A portion of the funds ar=
e in hot storage with live keys.=C2=A0 These funds can be stolen by anyone =
who gets 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 interventi=
on.<br><br></div><span><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-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></span><div>Set=
ting up offline keys to act as firebreaks is part of good security practice=
s.<br></div></div></div></div>
<br></div></div><span class=3D"">______________________________<wbr>_______=
__________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a114d6f1cd9dfd405398340f1--
|