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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Tg0Fh-00064T-Lg
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 21:42:05 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com;
helo=mail-ia0-f175.google.com;
Received: from mail-ia0-f175.google.com ([209.85.210.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tg0Fg-0007VJ-IQ
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 21:42:05 +0000
Received: by mail-ia0-f175.google.com with SMTP id z3so3462051iad.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 04 Dec 2012 13:41:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.195.135 with SMTP id ie7mr4273278igc.8.1354657319279; Tue,
04 Dec 2012 13:41:59 -0800 (PST)
Received: by 10.64.171.73 with HTTP; Tue, 4 Dec 2012 13:41:58 -0800 (PST)
In-Reply-To: <CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com>
References: <CANEZrP3=GdyTe+2=cp-ROOJ8_t=yCqO-7GQ4hA-3aksg46p+ww@mail.gmail.com>
<CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng@mail.gmail.com>
<CANEZrP3ZhNYrgQZT4qOohejs3yhgt0c_kT5zwAUVtPP1Q9f1Zg@mail.gmail.com>
Date: Tue, 4 Dec 2012 16:41:58 -0500
Message-ID: <CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Tg0Fg-0007VJ-IQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV clients
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: Tue, 04 Dec 2012 21:42:05 -0000
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn <mike@plan99.net> wrote:
>> It sounds to me that you're insisting that you're asking people who
>> oppose degrading our recommendations to commit to a costly rushed
>> development timeline. I think this is a false choice.
>
> Hardly. I don't have any particular timeline in mind. But I disagree
> we have "forever". New ideas have a certain time window to take off
> and become credible.
Marketing initiatives have limited windows. This matters, perhaps,
when you're some VC pumping cash into a startup with the hopes of
being the next stockmarket pump and dump darling. Outside of that
people use whatever they use because it works for them.
And by the numbers Linux desktops are more common than they've ever
been=E2=80=94 and certainly Linux kernel _systems_ half the people I know h=
ave
one in their pocket and its hard to go more than a few hours without
touching one. To some extent the "Year of the Linux desktop" is a bit
like the "Year of being able to turn lead into gold" ... we can turn
lead into gold now, but the particle accelerators, atomic power, and
atomic weapons enabled by the same technology are far more interesting
due to the particle realities of this. So we didn't get the ubiquitous
Linux desktop: We got the ubiquitious Linux server, the ubiquitous
Linux-kernel smart phone, the ubiquitous Linux television, media
player, HVAC controller, etc. instead.
Desktops=E2=80=94 well, that didn't meet people's hopes though I think not =
for
the lack of marketing on the part of Linux, but because Apple stepped
up and produced middle ground products that attracted a larger
audience. Especially as MSFT dropped the ball. They did some things
better, had a running start, and had a non open source software
business model which made reaping rewards easier.
But I don't see how any of this has anything to do with Bitcoin...
Except for the point that if Bitcoin doesn't become the money system
everyone uses and instead becomes the money system infrastructure all
the systems people use depend on=E2=80=94 just as Linux has with the deskto=
p,
where it might not be on the desktop but its in router firmware, cloud
servers, and just about everything else=E2=80=94 I wouldn't consider that m=
uch
of a loss.
> time window, eventually people just give up and move on. Does anyone
> take desktop Linux seriously anymore? No. "The year of desktop Linux"
> is a joke. People took it seriously in 2001 but despite great progress
> since, the excitement and attention has gone. There were steady
> improvements over the last 10 years but nobody is creating desktop
> Linux startups anymore
Bitcoin already missed its first=E2=80=94 and perhaps only=E2=80=94 fad win=
dow in any
case. Today people say "Bitcoin? Thats still around? I thought it got
hacked". ... thanks to compromised centralized services.
> It's unclear we need to have every man and his dog run a full node.
Every man and his dog? Perhaps not. But as many as can=E2=80=94 probably s=
o.
If we depend on the organic need for full nodes to overcome cost and
effort to run one there will always be major incentives to let someone
else do that, and the system would have its equilibrium right on the
brink of insecurity. Perhaps worse, since insecurity is most obvious
retrospectively. Security doesn't make for a good market force.
> Tor is a successful P2P network where the number of users vastly
> outstrips the number of nodes, and exit nodes in particular are a
> scarce resource run by people who know what they're doing and commit
> to it.
Tor is a distributed but controlled, by a small number of directory
authority operators, system.
It is a good system. But it has a trust model which is categorically
weaker than the one in Bitcoin. If you want something where a
majority of a dozen signing keys=E2=80=94 hopefully in the hands of trusted
parties=E2=80=94 can decide the state of the system you can produce sometin=
g
far superior to Bitcoin=E2=80=94 something that gives near instant
non-reversable transactions, something that gives good client security
without the complexity of a SPV node, etc.
But that isn't Bitcoin.
> Even with no incentives, they were able to obtain
> the resources they need.
And yet every tor user=E2=80=94 if the have the bandwidth available can be =
a
full internal relay and the software nags them to do it (and also nags
them to act as invisible bridges for blocking avoidance), and every
user is technically able to run an exit (though they don't bludgeon
users to do that, because of the legal/political/technical issues
involved). To do any of this doesn't require a user to switch to
different software, and the tor project has previously opposed client
only software.
> So why should Bitcoin be different?
It's less different than you make it out to be=E2=80=94 but it _is_ differe=
nt.
Bitcoin is a distributed currency. The value of bitcoin comes from
the soundness of its properties and from the persistence of its
security. If the integrity of the distributed ledger is disrupted the
damage produced, both in funds stolen and in undermining the
confidence of the system, can be irreversible. Because Bitcoin's value
comes from confidence in Bitcoin and not from the specific
functionality of Bitcoins (they're random numbers that sit on your
disk) even if the ledger isn't actually compromised but people
reasonably believe it could be compromised that undermines the value.
Tor, on the other hand, is a functioning system whos value depends on
its current usefulness, and not the past or future security.
Compare in your mind=E2=80=94 Say everyone just found out that at block
420,000 Bitcoin would stop enforcing signature correctness or block
subsidy values (and this wasn't going to be fixed), and you also found
out that one year from now Tor would hand over their sites, source
code repositories, and directory authority keys to Iran (and you have
no suspicion that they already had done so). How fast would you stop
using Tor vs how fast would to sell whatever coins you could?
> We can easily send a clear and consistent "this is important, please
> help" message without complicated auto-upgrade/downgrade schemes that
> risk annoying users.
I don't think we really can send such a message. Thanks just the same
as asking for donations, not completely unsuccessful but not easy to
make successful either. You're arguing for people running distinct
software which has no capability to be a full node, and changing what
they're doing in order to support the network. This maximizes the
cost, because in addition to the real cost the user must take a
switching cost too, and deemphasizes investing in keeping the full
node software as usable because 'oh just run a lite node if the full
is too slow'.
|
