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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1Tg1Dl-0003p6-TE
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 22:44:09 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=etotheipi@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tg1Dj-0008RA-76
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Dec 2012 22:44:09 +0000
Received: by mail-ob0-f175.google.com with SMTP id vb8so4615008obc.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 04 Dec 2012 14:44:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.170.10 with SMTP id ai10mr13348042oec.72.1354661041861;
Tue, 04 Dec 2012 14:44:01 -0800 (PST)
Received: by 10.76.170.230 with HTTP; Tue, 4 Dec 2012 14:44:01 -0800 (PST)
In-Reply-To: <CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@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>
<CAAS2fgSJhX4974BdWGdyJA13kHg7mTgHadC6UdhdUPu0bDDXFg@mail.gmail.com>
Date: Tue, 4 Dec 2012 17:44:01 -0500
Message-ID: <CALf2ePw82wt08_G2RtUYEBxorjY1ryZ4r+W7atSzDLYMU+rGGQ@mail.gmail.com>
From: Alan Reiner <etotheipi@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec54a35d430f32904d00e9a8d
X-Spam-Score: -0.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
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Tg1Dj-0008RA-76
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 22:44:10 -0000
--bcaec54a35d430f32904d00e9a8d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
This discussion sounds to be veering slightly off track. I think we should
be focusing on how we will ease the transition for new users to get on the
network and use it. Talking about the necessity and costs of running full
nodes in the future is important, but irrelevant here: unless we don't
want users who aren't willing to run full nodes, we need to accommodate
users who want to simply "use" the network, not necessarily "support" it. =
*I'm
making an assumption here that we want new users whether they use a full
node or not*. Greg's point looks like it's veering towards "we don't want
to grow the network unless we're going to get more full nodes out of it."
I'm of the opinion, like Mike Hearn, that the number of full nodes needed
for a healthy network is *not* O(N) in the number of users of the network.
I expect it to be something more like O(sqrt(N))... or perhaps there's
even an upper limit above which the network gets no benefit, even if all 7
billion humans were using it. (the bottleneck would be size of blocks and
CPU processing power at that point, not a shortage of full nodes). Would
we rather have a system that is "full-node-or-nothing" and drive away users
that won't support the network, or accommodate those users with various
gradations of participation?
I believe my proposal for an address-based meta-chain (or something like
it) is *exactly* what is needed in the long run. It could almost obsolete
this entire discussion. However, as Greg pointed out there is a long,
treacherous path between the theory I presented, and a working&robust
implementation that can serve as the backbone for future SPV nodes. I have
every intention to help pioneer that when Armory has other major features
completed (such as multi-sig), but it's not something that we can even
consider in the near- or medium-term as a solution to rely on. I'd be
surprised if any such solution existed in the next 6-12 months.
I think it is very much in everyone's interest here to encourage new users
to start "using" Bitcoin, even if they don't "support" it. As long as
there is a convenient channel for interested users to get more information
about the system, the benefits of spending the effort to run a full node,
and the features available in more-advanced clients that they might benefit
from, then I'm not personally concerned about a shortage of full nodes, and
we should carry forward with the idea of promoting SPV nodes for the
really-new users.
-Alan
On Tue, Dec 4, 2012 at 4:41 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 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=97 and certainly Linux kernel _systems_ half the people I know have
> 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=97 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=97 just as Linux has with the desktop,
> where it might not be on the desktop but its in router firmware, cloud
> servers, and just about everything else=97 I wouldn't consider that much
> 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=97 and perhaps only=97 fad window 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=97 probably so.
>
> 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=97 hopefully in the hands of trusted
> parties=97 can decide the state of the system you can produce someting
> far superior to Bitcoin=97 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=97 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=97 but it _is_ different.
> 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=97 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'.
>
>
> -------------------------------------------------------------------------=
-----
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--bcaec54a35d430f32904d00e9a8d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
This discussion sounds to be veering slightly off track. =A0I think we shou=
ld be focusing on how we will ease the transition for new users to get on t=
he network and use it. =A0Talking about the necessity and costs of running =
full nodes in the future is important, but irrelevant here: =A0unless we do=
n't want users who aren't willing to run full nodes, we need to acc=
ommodate users who want to simply "use" the network, not necessar=
ily "support" it. =A0<i>I'm making an assumption here that we=
want new users whether they use a full node or not</i>. =A0Greg's poin=
t looks like it's veering towards "we don't want to grow the n=
etwork unless we're going to get more full nodes out of it." =A0 =
=A0=A0I'm of the opinion, like Mike Hearn, that the number of full node=
s needed for a healthy network is <u>not</u> O(N) in the number of users of=
the network. =A0I expect it to be something more like O(sqrt(N))... or per=
haps there's even an upper limit above which the network gets no benefi=
t, even if all 7 billion humans were using it. =A0(the bottleneck would be =
size of blocks and CPU processing power at that point, not a shortage of fu=
ll nodes). =A0Would we rather have a system that is "full-node-or-noth=
ing" and drive away users that won't support the network, or accom=
modate those users with various gradations of participation?<div>
<div><br></div><div>I believe my proposal for an address-based meta-chain (=
or something like it) is <b>exactly</b>=A0what is needed in the long run. =
=A0It could almost obsolete this entire discussion. =A0However, as Greg poi=
nted out there is a long, treacherous path between the theory I presented, =
and a working&robust implementation that can serve as the backbone for =
future SPV nodes. =A0I have every intention to help pioneer that when Armor=
y has other major features completed (such as multi-sig), but it's not =
something that we can even consider in the near- or medium-term as a soluti=
on to rely on. =A0I'd be surprised if any such solution existed in the =
next 6-12 months.=A0</div>
<div><br></div><meta http-equiv=3D"content-type" content=3D"text/html; char=
set=3Dutf-8"><div>I think it is very much in everyone's interest here t=
o encourage new users to start "using" Bitcoin, even if they don&=
#39;t "support" it. =A0As long as there is a convenient channel f=
or interested users to get more information about the system, the benefits =
of spending the effort to run a full node, and the features available in mo=
re-advanced clients that they might benefit from, then I'm not personal=
ly concerned about a shortage of full nodes, and we should carry forward wi=
th the idea of promoting SPV nodes for the really-new users.</div>
<div><br></div><div>-Alan</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Dec 4, 2012 a=
t 4:41 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mailto:gmaxwell=
@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Dec 4, 2012 at 3:5=
8 PM, Mike Hearn <<a href=3D"mailto:mike@plan99.net">mike@plan99.net</a>=
> wrote:<br>
>> It sounds to me that you're insisting that you're asking p=
eople who<br>
>> oppose degrading our recommendations to commit to a costly rushed<=
br>
>> development timeline. I think this is a false choice.<br>
><br>
> Hardly. I don't have any particular timeline in mind. But I disagr=
ee<br>
> we have "forever". New ideas have a certain time window to t=
ake off<br>
> and become credible.<br>
<br>
</div>Marketing initiatives have limited windows. =A0This matters, perhaps,=
<br>
when you're some VC pumping cash into a startup with the hopes of<br>
being the next stockmarket pump and dump darling. =A0Outside of that<br>
people use whatever they use because it works for them.<br>
<br>
And by the numbers Linux desktops are more common than they've ever<br>
been=97 and certainly Linux kernel _systems_ half the people I know have<br=
>
one in their pocket and its hard to go more than a few hours without<br>
touching one. =A0To some extent the "Year of the Linux desktop" i=
s a bit<br>
like the "Year of being able to turn lead into gold" ... we can t=
urn<br>
lead into gold now, but the particle accelerators, atomic power, and<br>
atomic weapons enabled by the same technology are far more interesting<br>
due to the particle realities of this. So we didn't get the ubiquitous<=
br>
Linux desktop: We got the ubiquitious Linux server, the ubiquitous<br>
Linux-kernel smart phone, the ubiquitous Linux television, media<br>
player, HVAC controller, etc. instead.<br>
<br>
Desktops=97 well, that didn't meet people's hopes though I think no=
t for<br>
the lack of marketing on the part of Linux, but because Apple stepped<br>
up and produced middle ground products that attracted a larger<br>
audience. Especially as MSFT dropped the ball. They did some things<br>
better, had a running start, and had a non open source software<br>
business model which made reaping rewards easier.<br>
<br>
But I don't see how any of this has anything to do with Bitcoin...<br>
Except for the point that if Bitcoin doesn't become the money system<br=
>
everyone uses and instead becomes the money system infrastructure all<br>
the systems people use depend on=97 just as Linux has with the desktop,<br>
where it might not be on the desktop but its in router firmware, cloud<br>
servers, and just about everything else=97 I wouldn't consider that muc=
h<br>
of a loss.<br>
<div class=3D"im"><br>
> time window, eventually people just give up and move on. Does anyone<b=
r>
> take desktop Linux seriously anymore? No. "The year of desktop Li=
nux"<br>
> is a joke. People took it seriously in 2001 but despite great progress=
<br>
> since, the excitement and attention has gone. There were steady<br>
> improvements over the last 10 years but nobody is creating desktop<br>
> Linux startups anymore<br>
<br>
</div>Bitcoin already missed its first=97 and perhaps only=97 fad window in=
any<br>
case. Today people say "Bitcoin? Thats still around? I thought it got<=
br>
hacked". ... thanks to compromised centralized services.<br>
<div class=3D"im"><br>
> It's unclear we need to have every man and his dog run a full node=
.<br>
<br>
</div>Every man and his dog? Perhaps not. =A0But as many as can=97 probably=
so.<br>
<br>
If we depend on the organic need for full nodes to overcome cost and<br>
effort to run one there will always be major incentives to let someone<br>
else do that, and the system would have its equilibrium right on the<br>
brink of insecurity. Perhaps worse, since insecurity is most obvious<br>
retrospectively. Security doesn't make for a good market force.<br>
<div class=3D"im"><br>
> Tor is a successful P2P network where the number of users vastly<br>
> outstrips the number of nodes, and exit nodes in particular are a<br>
> scarce resource run by people who know what they're doing and comm=
it<br>
> to it.<br>
<br>
</div>Tor is a distributed but controlled, by a small number of directory<b=
r>
authority operators, system.<br>
<br>
It is a good system. But it has a trust model which is categorically<br>
weaker than the one in Bitcoin. =A0If you want something where a<br>
majority of a dozen signing keys=97 hopefully in the hands of trusted<br>
parties=97 can decide the state of the system you can produce someting<br>
far superior to Bitcoin=97 something that gives near instant<br>
non-reversable transactions, something that gives good client security<br>
without the complexity of a SPV node, etc.<br>
<br>
But that isn't Bitcoin.<br>
<div class=3D"im"><br>
> Even with no incentives, they were able to obtain<br>
> the resources they need.<br>
<br>
</div>And yet every tor user=97 if the have the bandwidth available can be =
a<br>
full internal relay and the software nags them to do it (and also nags<br>
them to act as invisible bridges for blocking avoidance), and every<br>
user is technically able to run an exit (though they don't bludgeon<br>
users to do that, because of the legal/political/technical issues<br>
involved). =A0To do any of this doesn't require a user to switch to<br>
different software, and the tor project has previously opposed client<br>
only software.<br>
<div class=3D"im"><br>
> So why should Bitcoin be different?<br>
<br>
</div>It's less different than you make it out to be=97 but it _is_ dif=
ferent.<br>
=A0 Bitcoin is a distributed currency. The value of bitcoin comes from<br>
the soundness of its properties and from the persistence of its<br>
security. If the integrity of the distributed ledger is disrupted the<br>
damage produced, both in funds stolen and in undermining the<br>
confidence of the system, can be irreversible. Because Bitcoin's value<=
br>
comes from confidence in Bitcoin and not from the specific<br>
functionality of Bitcoins (they're random numbers that sit on your<br>
disk) even if the ledger isn't actually compromised but people<br>
reasonably believe it could be compromised that undermines the value.<br>
=A0Tor, on the other hand, is a functioning system whos value depends on<br=
>
its current usefulness, and not the past or future security.<br>
<br>
Compare in your mind=97 Say everyone just found out that at block<br>
420,000 Bitcoin would stop enforcing signature correctness or block<br>
subsidy values (and this wasn't going to be fixed), and you also found<=
br>
out that one year from now Tor would hand over their sites, source<br>
code repositories, and directory authority keys to Iran (and you have<br>
no suspicion that they already had done so). =A0 How fast would you stop<br=
>
using Tor vs how fast would to sell whatever coins you could?<br>
<div class=3D"im"><br>
> We can easily send a clear and consistent "this is important, ple=
ase<br>
> help" message without complicated auto-upgrade/downgrade schemes =
that<br>
> risk annoying users.<br>
<br>
</div>I don't think we really can send such a message. =A0Thanks just t=
he same<br>
as asking for donations, not completely unsuccessful but not easy to<br>
make successful either. =A0You're arguing for people running distinct<b=
r>
software which has no capability to be a full node, and changing what<br>
they're doing in order to support the network. This maximizes the<br>
cost, because in addition to the real cost the user must take a<br>
switching cost too, and deemphasizes investing in keeping the full<br>
node software as usable because 'oh just run a lite node if the full<br=
>
is too slow'.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial<br>
Remotely access PCs and mobile devices and provide instant support<br>
Improve your efficiency, and focus on delivering more value-add services<br=
>
Discover what IT Professionals Know. Rescue delivers<br>
<a href=3D"http://p.sf.net/sfu/logmein_12329d2d" target=3D"_blank">http://p=
.sf.net/sfu/logmein_12329d2d</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--bcaec54a35d430f32904d00e9a8d--
|