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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <21xe14@gmail.com>) id 1Y9fMA-0004qs-Ps
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 19:36:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.46 as permitted sender)
client-ip=74.125.82.46; envelope-from=21xe14@gmail.com;
helo=mail-wg0-f46.google.com;
Received: from mail-wg0-f46.google.com ([74.125.82.46])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y9fM8-0006Xz-Oj
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 19:36:26 +0000
Received: by mail-wg0-f46.google.com with SMTP id x13so9860664wgg.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Jan 2015 11:36:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.195.13.104 with SMTP id ex8mr36156960wjd.12.1420832178692;
Fri, 09 Jan 2015 11:36:18 -0800 (PST)
Received: by 10.27.131.17 with HTTP; Fri, 9 Jan 2015 11:36:18 -0800 (PST)
In-Reply-To: <CANEZrP3VXnX7B7wQ4LOUCs+aifx747svyo5Gysw1SG0bgcT+WA@mail.gmail.com>
References: <CAFZQHkFP81iYsAadejL1Si60FgtQSLvN==67ft2YRtsL9MqyDg@mail.gmail.com>
<CANEZrP3VXnX7B7wQ4LOUCs+aifx747svyo5Gysw1SG0bgcT+WA@mail.gmail.com>
Date: Fri, 9 Jan 2015 19:36:18 +0000
Message-ID: <CAFZQHkF8mpPcGw0QnVed0rAxC7oOo2C6aNWrL3a+-vMYC2KroQ@mail.gmail.com>
From: 21E14 <21xe14@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bfd09204be8cd050c3d45a5
X-Spam-Score: -0.3 (/)
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
(21xe14[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (21xe14[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
X-Headers-End: 1Y9fM8-0006Xz-Oj
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 19:36:26 -0000
--047d7bfd09204be8cd050c3d45a5
Content-Type: text/plain; charset=UTF-8
> 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.
Let me translate it to this year's vocabulary. Think of BCIs as a
sidechain: let the legacy financial system migrate, to the extent desired,
to a more heavily regulated pegged sidechain with a stronger identity
layer. Let protocol-level rules regulate this nexus between the custodial
(sidechain) and non-custodial address spaces (blockchain). This isn't
entirely unlike the rules currently governing coin issuance i.e. coinbase
transactions. Let the market forces play it out. Iterate as needed. I
suspect that in retrospect it'll seem obvious. Many moons from now the
balance might shift between the two, but it won't matter much. The system
will have means to recover from catastrophic failure modes.
To help internalize such an evolution, please consider the layers the
Bitcoin protocol builds on top of: segment 52:32 ("The Internet is being
upgraded") of the BBC documentary "Inside The Dark Web" (
https://www.youtube.com/watch?v=qXajND7BQzk#t=3152). Kaspersky's comments a
few minutes earlier (50:06) aren't entirely out of context here either.
Clearly, the need is acute for Bitcoin to become institutional i.e. for
"billions of dollars of human value" to flow through it, as one Money 20/20
participant put it.
On Fri, Jan 9, 2015 at 2:00 PM, Mike Hearn <mike@plan99.net> wrote:
> 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.
>
--047d7bfd09204be8cd050c3d45a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> I think the observation about Target vs Bitcoin excha=
nges is a sharp one,<br>> but I'm not sure how your proposal helps. =
You say it's an optional identity<br>> layer, but obviously any thie=
f is going to opt out of being identified.<br><br>Let me translate it to th=
is year's vocabulary. Think of BCIs as a sidechain: let the legacy fina=
ncial system migrate, to the extent desired, to a more heavily regulated pe=
gged sidechain with a stronger identity layer. Let protocol-level rules reg=
ulate this nexus between the custodial (sidechain) and non-custodial addres=
s spaces (blockchain). This isn't entirely unlike the rules currently g=
overning coin issuance i.e. coinbase transactions. Let the market forces pl=
ay it out. Iterate as needed. I suspect that in retrospect it'll seem o=
bvious. Many moons from now the balance might shift between the two, but it=
won't matter much. The system will have means to recover from catastro=
phic failure modes.<br><br>To help internalize such an evolution, please co=
nsider the layers the Bitcoin protocol builds on top of: segment 52:32 (&qu=
ot;The Internet is being upgraded") of the BBC documentary "Insid=
e The Dark Web" (<a href=3D"https://www.youtube.com/watch?v=3DqXajND7B=
Qzk#t=3D3152">https://www.youtube.com/watch?v=3DqXajND7BQzk#t=3D3152</a>). =
Kaspersky's comments a few minutes earlier (50:06) aren't entirely =
out of context here either. Clearly, the need is acute for Bitcoin to becom=
e institutional i.e. for "billions of dollars of human value" to =
flow through it, as one Money 20/20 participant put it.<br><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jan 9, 2015 at 2:00=
PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" ta=
rget=3D"_blank">mike@plan99.net</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc 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, as proposed in late August of last year on th=
is mailing list</div></blockquote><div><br></div></span><div>I think the ob=
servation 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.</div><div=
><br></div><div>For things like the Bitstamp hack, it's not clear how i=
dentity can help, because they were already doing KYC for all their custome=
rs. To take that further at the protocol level would require<i>=C2=A0all</i=
>=C2=A0transactions to have attached identity info, and that isn't goin=
g to happen - it wouldn't be Bitcoin, at that point.</div><div><br></di=
v><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 bu=
t we'll see). You can have very minimalist secure hardware that would h=
ave some additional policies on top, like refusing to sign transactions wit=
hout an identity proof of who controls the target address. Very tight hot w=
allets that risk analyse the instructions they're receiving have been p=
roposed years ago.=C2=A0</div><div><br></div><div>No such hardware presentl=
y exists, but that's mostly because implementations always lag behind a=
long way behind ideas rather than any fundamental technical bottleneck. Pe=
rhaps the Bitstamp event will finally spur development of such things forwa=
rd.</div></div></div></div>
</blockquote></div><br></div></div>
--047d7bfd09204be8cd050c3d45a5--
|
