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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <21xe14@gmail.com>) id 1YDoRl-0004iY-So
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Jan 2015 06:07:21 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.179 as permitted sender)
client-ip=209.85.212.179; envelope-from=21xe14@gmail.com;
helo=mail-wi0-f179.google.com;
Received: from mail-wi0-f179.google.com ([209.85.212.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YDoRj-0005Ir-EX
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Jan 2015 06:07:21 +0000
Received: by mail-wi0-f179.google.com with SMTP id l15so20093818wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 20 Jan 2015 22:07:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.206.229 with SMTP id lr5mr52855341wic.74.1421820433381;
Tue, 20 Jan 2015 22:07:13 -0800 (PST)
Received: by 10.27.14.215 with HTTP; Tue, 20 Jan 2015 22:07:13 -0800 (PST)
Date: Wed, 21 Jan 2015 06:07:13 +0000
Message-ID: <CAFZQHkFfpTw2rua8D21BEB9S723+VQ+8xt19AjPm0_iQSs5YuQ@mail.gmail.com>
From: 21E14 <21xe14@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c38a22ddc13d050d235d2e
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: 1YDoRj-0005Ir-EX
Cc: joi@media.mit.edu
Subject: [Bitcoin-development] Why Bitcoin is and isn't like the Internet
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: Wed, 21 Jan 2015 06:07:22 -0000
--001a11c38a22ddc13d050d235d2e
Content-Type: text/plain; charset=UTF-8
This is a response to a wonderfully insightful recent post by Joichi Ito,
the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board
Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the
Internet" and asked a most pertinent question: "Whether there is an ICANN
equivalent needed for Bitcoin." As suggested in recent posts to the mailing
list, I believe there might be, but for a reason that may not seem obvious
at first.
Alan Reiner expressed the need this way: "I think one of the biggest issues
facing Bitcoin right now is not the lack of a 'killer app.' It is lack of
insurance options. Early adopters would like to believe that the majority
of users will hold their own Bitcoin, but I believe that is not a realistic
option when life-changing quantities of Bitcoin are involved. We should not
trust Grandma to secure her own retirement savings via complicated computer
maneuvers. More to the point, she should not trust herself or anyone else
(sic!) to hold it unless there is a strong protection against loss events.
Right now the solution is for Grandma to avoid keeping her money in
Bitcoin. Bitcoin needs a strong backbone of insured storage options so that
Grandma can confidently participate in this new technology." This is
certainly an observation to take heed of coming from the founder of Armory
Technologies.
The protection against loss events ought to be understood in the broadest
sense. What is needed is a disaster recovery mechanism. Andreas
Antonopoulos remarks expressed this candidly last year: "Bitcoin doesn't
have a middle of the road mediocre growth model. It basically either dies,
because of a fundamental flaw in the Bitcoin system. Not an external
factor, an internal factor: We blow it up by accident. And that could
happen... Bitcoin will play out in the next three years. In the next three
years we're going to see Bitcoin arrive on the global stage and make a
substantial impact, both in financial terms and in political terms. It will
happen. Or it will die. Either way. I'm not sure. In which case we'll
reboot another currency."
A body, not entirely unlike ICANN, can manage the nexus to the physical
world, and help address Bitcoin's catastrophic failure modes. Bitcoin's
coin ownership protocol would thus join the ranks of its payment protocol,
coin issuance protocol, consensus mechanism and inflation control that pose
no lethal threat to the ecosystem. In addition to their coin-agnostic
nature, I suspect the high valuation of large Bitcoin hubs relative to
Bitcoin's market cap at this stage in its lifecycle is partly reflective of
the sneaking suspicion that a custodial bitcoin (a bitcoin attached to an
identity) may be worth more than a non-custodial one. With this in mind,
I'll pitch in for the ticket should Dr. Ito decide to join the next month's
DevCore Boston conference aimed at supporting the future development of
Bitcoin. It's an hour's walk from MIT after all.
--001a11c38a22ddc13d050d235d2e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is a response to a wonderfully insightful recent post=
by Joichi Ito, the Director of the MIT Media Lab. In it, Dr. Ito, notably =
a former Board Member of ICANN, offered his thoughts on "Why Bitcoin i=
s and isn't like the Internet" and asked a most pertinent question=
: "Whether there is an ICANN equivalent needed for Bitcoin." As s=
uggested in recent posts to the mailing list, I believe there might be, but=
for a reason that may not seem obvious at first.<br><br>Alan Reiner expres=
sed the need this way: "I think one of the biggest issues facing Bitco=
in right now is not the lack of a 'killer app.' It is lack of insur=
ance options. Early adopters would like to believe that the majority of use=
rs will hold their own Bitcoin, but I believe that is not a realistic optio=
n when life-changing quantities of Bitcoin are involved. We should not trus=
t Grandma to secure her own retirement savings via complicated computer man=
euvers. More to the point, she should not trust herself or anyone else (sic=
!) to hold it unless there is a strong protection against loss events. Righ=
t now the solution is for Grandma to avoid keeping her money in Bitcoin. Bi=
tcoin needs a strong backbone of insured storage options so that Grandma ca=
n confidently participate in this new technology." This is certainly a=
n observation to take heed of coming from the founder of Armory Technologie=
s.<br><br>The protection against loss events ought to be understood in the =
broadest sense. What is needed is a disaster recovery mechanism. Andreas An=
tonopoulos remarks expressed this candidly last year: "Bitcoin doesn&#=
39;t have a middle of the road mediocre growth model. It basically either d=
ies, because of a fundamental flaw in the Bitcoin system. Not an external f=
actor, an internal factor: We blow it up by accident. And that could happen=
... Bitcoin will play out in the next three years. In the next three years =
we're going to see Bitcoin arrive on the global stage and make a substa=
ntial impact, both in financial terms and in political terms. It will happe=
n. Or it will die. Either way. I'm not sure. In which case we'll re=
boot another currency."<br><br>A body, not entirely unlike ICANN, can =
manage the nexus to the physical world, and help address Bitcoin's cata=
strophic failure modes. Bitcoin's coin ownership protocol would thus jo=
in the ranks of its payment protocol, coin issuance protocol, consensus mec=
hanism and inflation control that pose no lethal threat to the ecosystem. I=
n addition to their coin-agnostic nature, I suspect the high valuation of l=
arge Bitcoin hubs relative to Bitcoin's market cap at this stage in its=
lifecycle is partly reflective of the sneaking suspicion that a custodial =
bitcoin (a bitcoin attached to an identity) may be worth more than a non-cu=
stodial one. With this in mind, I'll pitch in for the ticket should Dr.=
Ito decide to join the next month's DevCore Boston conference aimed at=
supporting the future development of Bitcoin. It's an hour's walk =
from MIT after all.<br></div>
--001a11c38a22ddc13d050d235d2e--
|
