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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A0A74481
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 15:55:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com
[209.85.217.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC162F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 15:55:52 +0000 (UTC)
Received: by lbbud7 with SMTP id ud7so26053124lbb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 08:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=okAhCAFjp+N0s/xrelg9FP7CiVSanrDfqVXcuosuiKs=;
b=B/vlHzG7Nmk/LvrVGA+OrjY76tJhdCNRqM8bad8Im4vje9U6L1L0qCcsOcUi5xJfja
52tbC4HPfBqRSgDRqBLmjtTEMvjGY8CoMgwqTjEOn4r0ireHHqZOcLonY1JTUw4dMTX5
8J6tG1Txp6aXpa8ogoojjq/qhBiZVUvmQLOjUnnNJBsH3zlrsqGjaJ4V1XC/FJBAzfv4
M+/RTKByf6CLDNKpPrAKBw76V+7cC6LIdI/0VOGQJ4n1WEdMFxz7sA2CeC3UEvsS6pmD
s20k6urLfxAzqDZDXSmSAcPo2/JEvag4CQEZnnJxtV9UMBOvM+swLhyNGH8h5+4WFfH/
5Eyw==
MIME-Version: 1.0
X-Received: by 10.152.203.233 with SMTP id kt9mr39643987lac.99.1438271750776;
Thu, 30 Jul 2015 08:55:50 -0700 (PDT)
Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 08:55:50 -0700 (PDT)
In-Reply-To: <CABaSBaxyQja9bqDsyfWubR1R-Xf2tqmSmU-GW_z7VQTxbBagrQ@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<55B9EB68.9020703@mail.bihthai.net>
<CABm2gDpJjimF486qca=JGQ0h6k9qzike-hjVUU2NhOuCzbBkow@mail.gmail.com>
<2905605.OvbZMWuhGy@coldstorage>
<CABaSBaxyQja9bqDsyfWubR1R-Xf2tqmSmU-GW_z7VQTxbBagrQ@mail.gmail.com>
Date: Thu, 30 Jul 2015 11:55:50 -0400
Message-ID: <CABsx9T3FoErEeOtQcnK62WK=zOBREwRkxzDNLDniuvM+L5Shiw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary=001a11345984cbad0d051c19bc42
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
isn'ttemporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 15:55:53 -0000
--001a11345984cbad0d051c19bc42
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Because any decentralized system is going to have high transaction costs
> and scarcity anyway.
This is a meme that keeps coming up that I think just isn't true.
What other decentralized systems can we look at as role models?
How decentralized are they?
And why did they succeed when "more efficient" centralized systems did not?
The Internet is the most successful decentralized system to date; what
lessons should we learn?
How decentralized is the technology of the Internet (put aside governance
and the issues of who-assigns-blocks-of-IPs-and-registers-domain-names)?
How many root DNS servers? How many BGP routers along the backbone would
need to be compromised to disrupt traffic? Why don't we see more
disruptions, or why are people willing to tolerate the disruptions that DO
happen?
And how did the Internet out-compete more efficient centralized systems
from the big telecom companies? (I remember some of the arguments that
unreliable, inefficient packet-switching would never replace dedicated
circuits that couldn't get congested and didn't have inefficient timeouts
and retransmissions)
What other successful or unsuccessful decentralized systems should we be
looking at?
I'm old-- I graduated from college in 1988, so I've worked in tech through
the entire rise of the Internet. The lessons I believe we should take away
is that a system doesn't have to be perfect to be successful, and we
shouldn't underestimate people's ability to innovate around what might seem
to be insurmountable problems, IF people are given the ability to innovate.
Yes, people will innovate within a 1MB (or 1MB-scaling-to-2MB by 2021) max
block size, and yes, smaller blocks have utility. But I think we'll get a
lot more innovation and utility without such small, artificial limits.
--
--
Gavin Andresen
--001a11345984cbad0d051c19bc42
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">On T=
hu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">Because any decentralized system is going to have =
high transaction costs and scarcity anyway.</blockquote></div><br>This is a=
meme that keeps coming up that I think just isn't true.</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What other decentral=
ized systems can we look at as role models?</div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra">How decentralized are they?</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And why did the=
y succeed when "more efficient" centralized systems did not?</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">The Internet is the most successful decentralize=
d system to date; what lessons should we learn?</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">How decentralized is the technolo=
gy of the Internet (put aside governance and the issues of who-assigns-bloc=
ks-of-IPs-and-registers-domain-names)? How many root DNS servers?=C2=A0 How=
many BGP routers along the backbone would need to be compromised to disrup=
t traffic? Why don't we see more disruptions, or why are people willing=
to tolerate the disruptions that DO happen?</div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">And how did the Internet out-compete=
more efficient centralized systems from the big telecom companies? =C2=A0(=
I remember some of the arguments that unreliable, inefficient packet-switch=
ing would never replace dedicated circuits that couldn't get congested =
and didn't have inefficient timeouts and retransmissions)<br><div><br><=
/div><div><br></div><div>What other successful or unsuccessful decentralize=
d systems should we be looking at?</div><div><br></div><div><br></div><div>=
I'm old-- I graduated from college in 1988, so I've worked in tech =
through the entire rise of the Internet. The lessons I believe we should ta=
ke away is that a system doesn't have to be perfect to be successful, a=
nd we shouldn't underestimate people's ability to innovate around w=
hat might seem to be insurmountable problems, IF people are given the abili=
ty to innovate.</div><div><br></div><div>Yes, people will innovate within a=
1MB (or 1MB-scaling-to-2MB by 2021) max block size, and yes, smaller block=
s have utility. But I think we'll get a lot more innovation and utility=
without such small, artificial limits.</div><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">--<br>Gavin Andresen<br></div><div class=3D"gmail_si=
gnature"><br></div>
</div></div>
--001a11345984cbad0d051c19bc42--
|
