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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Y9a7e-0007Hy-Js
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 14:01:06 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y9a7d-0005kI-OD
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 14:01:06 +0000
Received: by mail-wg0-f53.google.com with SMTP id x13so8262733wgg.12
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Jan 2015 06:00:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.82.98 with SMTP id h2mr5420507wiy.7.1420812059253; Fri,
09 Jan 2015 06:00:59 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Fri, 9 Jan 2015 06:00:59 -0800 (PST)
In-Reply-To: <CAFZQHkFP81iYsAadejL1Si60FgtQSLvN==67ft2YRtsL9MqyDg@mail.gmail.com>
References: <CAFZQHkFP81iYsAadejL1Si60FgtQSLvN==67ft2YRtsL9MqyDg@mail.gmail.com>
Date: Fri, 9 Jan 2015 15:00:59 +0100
X-Google-Sender-Auth: zkvVHyvavhvaOz3s9Iqate5ziv8
Message-ID: <CANEZrP3VXnX7B7wQ4LOUCs+aifx747svyo5Gysw1SG0bgcT+WA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: 21E14 <21xe14@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044283ec15c18d050c3896bf
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Y9a7d-0005kI-OD
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A look back and a look forward
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 14:01:06 -0000
--f46d044283ec15c18d050c3896bf
Content-Type: text/plain; charset=UTF-8
>
> This needn't be so, once an optional identity layer, modeled after the
> Internet itself, is provided, as proposed in late August of last year on
> this mailing list
>
I think the observation about Target vs Bitcoin exchanges is a sharp one,
but I'm not sure how your proposal helps. You say it's an optional identity
layer, but obviously any thief is going to opt out of being identified.
For things like the Bitstamp hack, it's not clear how identity can help,
because they were already doing KYC for all their customers. To take that
further at the protocol level would require* all* transactions to have
attached identity info, and that isn't going to happen - it wouldn't be
Bitcoin, at that point.
I think that long term, it's probably possible to defend private keys
adequately, even for large sums of money (maybe not bitstamp-large but
we'll see). You can have very minimalist secure hardware that would have
some additional policies on top, like refusing to sign transactions without
an identity proof of who controls the target address. Very tight hot
wallets that risk analyse the instructions they're receiving have been
proposed years ago.
No such hardware presently exists, but that's mostly because
implementations always lag behind a long way behind ideas rather than any
fundamental technical bottleneck. Perhaps the Bitstamp event will finally
spur development of such things forward.
--f46d044283ec15c18d050c3896bf
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">This needn't be so, once an=
optional identity layer, modeled after the Internet itself, is provided, a=
s proposed in late August of last year on this mailing list</div></blockquo=
te><div><br></div><div>I think the observation about Target vs Bitcoin exch=
anges is a sharp one, but I'm not sure how your proposal helps. You say=
it's an optional identity layer, but obviously any thief is going to o=
pt out of being identified.</div><div><br></div><div>For things like the Bi=
tstamp hack, it's not clear how identity can help, because they were al=
ready doing KYC for all their customers. To take that further at the protoc=
ol level would require<i>=C2=A0all</i>=C2=A0transactions to have attached i=
dentity info, and that isn't going to happen - it wouldn't be Bitco=
in, at that point.</div><div><br></div><div>I think that long term, it'=
s probably possible to defend private keys adequately, even for large sums =
of money (maybe not bitstamp-large but we'll see). You can have very mi=
nimalist secure hardware that would have some additional policies on top, l=
ike refusing to sign transactions without an identity proof of who controls=
the target address. Very tight hot wallets that risk analyse the instructi=
ons they're receiving have been proposed years ago.=C2=A0</div><div><br=
></div><div>No such hardware presently exists, but that's mostly becaus=
e implementations always lag behind a long way behind ideas rather than any=
fundamental technical bottleneck. Perhaps the Bitstamp event will finally =
spur development of such things forward.</div></div></div></div>
--f46d044283ec15c18d050c3896bf--
|
