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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SfZlw-0005VE-9s
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 16:53:20 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com;
helo=mail-vc0-f175.google.com;
Received: from mail-vc0-f175.google.com ([209.85.220.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SfZlv-0000Um-Bs
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 16:53:20 +0000
Received: by vcbfl15 with SMTP id fl15so2003489vcb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 09:53:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.221.13.65 with SMTP id pl1mr3363627vcb.61.1339779193827; Fri,
15 Jun 2012 09:53:13 -0700 (PDT)
Received: by 10.220.199.197 with HTTP; Fri, 15 Jun 2012 09:53:13 -0700 (PDT)
In-Reply-To: <CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
<CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com>
Date: Fri, 15 Jun 2012 12:53:13 -0400
Message-ID: <CAAS2fgQ8Yo=t+owLWLXeqOKFXcaYcJA4dXube-z9Lh_UeQnuLw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SfZlv-0000Um-Bs
Subject: [Bitcoin-development] Near-term scalability
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, 15 Jun 2012 16:53:20 -0000
[I originally sent an earlier version of this message to Mike off
list, but I figure it's worth adding to the public discussion]
On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn <mike@plan99.net> wrote:
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
> On the forums Matt stated that block chain pruning was a no-go because
> "it makes bitcoin more centralized". I think we've thrashed this one
> out sufficiently well by now that there should be a united opinion on
> it.
By itself letting the size float has non-trivial existential risk. =C2=A0A
Bitcoin with expensive transactions due to competition for space in
blocks can be front-ended with fast payment systems and still provide
the promised decentralized currency. Bitcoin with a very large
blockchain and blocks does not. =C2=A0It would do the bitcoin users no good
to increase the transaction volume while concurrently making Bitcoin
more or less pointless over the alternatives.
Scalability must be improved, we can unite on that opinion. =C2=A0But
scalability can't come at the expense of what made Bitcoin worth
having in the first place.
Fortunately it appear to be possible to greatly increase the
scalability without compromising on keeping the costs of operating a
fully validating node very low, =C2=A0for example Pieter's experimentation
with txout+txid indexing (for the 'flip the chain' proposals)
indicates that the data required right now to validate further
transactions is only about 85MiB=E2=80=94 and that would be somewhat smalle=
r
with compression and with clients which intentionally try to reduce
the set of unspent transactions. =C2=A0 Commitments to these indexes in the
chain would allow almost-full validating nodes with fairly limited
resources. (Almost-full meaning they would not validate the history
long before they started, they'd trusted header difficulty for that. They
could still mine and otherwise act as full nodes).
Achieving scalability improvements without breaking the radical
decentralization will be a lot harder than just improving scalability
but it's effort that is justified if the scalability is actually
needed.
How much decentralization is needed in the end? That isn't clear=E2=80=94 =
"As
much as possible" should generally be the goal. Modern currencies
aren't controlled by single parties but by tens of thousands of
parties locked in economic, legal, and political compromise that
limits their control. In Bitcoin the traditional controls that keep
parties honest are non-existent and if they were just directly applied
we'd potentially lose the properties that make Bitcoin distinct and
useful (e.g. make all miners mine only with FED permission and you
just have a really bandwidth inefficient interface to the dollar).
Instead we have aggressive decentralization and autonomous rule
enforcement.
Mike pointed out that "Before he left Satoshi made a comment saying
he used to think Bitcoin would need millions of nodes if it became
really popular, but in the end he thought it could do fine with just
tens of thousands" I'm not so sure=E2=80=94 and I think the truth is in
between. Tens of thousands of nodes=E2=80=94 run by a self-selecting bunch=
of
people who reap the greatest rewards from controlling the validation
of Bitcoin, who by that criteria necessarily have a lot in common with
each other and perhaps not with the regular users=E2=80=94 could easily be =
an
outcome where control is _less_ publicly vested than popular
government controlled currencies. We probably don't need the raw
numbers of nodes, but we need a distribution of ownership and a
distribution of interest (e.g. not a system by bankers for bankers) of
those nodes which I think can only be achieved by making them cheap to
operate and having a lot more than we actually need. =E2=80=94 though not s=
o
much that it has to run on every laptop.
The core challenge is that the only obvious ways to justify the cost
of maintaining expensive validation infrastructure is because you
intend to manipulate the currency using it or because you intend to
prevent other people from manipulating the currency. The latter
motivation is potentially subject to a tragedy of the commons=E2=80=94 you
don't need to run a full validating node as long as 'enough' other
people do, and enough is a nice slippery slope to zero. Right now
just the random computers I=E2=80=94 some random geek=E2=80=94 had at home =
prior to
Bitcoin could store over a hundred years of max size blocks and
process the maximum rate of transactions. With the costs so low
there isn't any real question about a consolidation of validation
making Bitcoin pointless. You could probably increase the scale 10x
without breaking that analysis but beyond that unless the
cost-per-scale goes down a highly consolidated future seems likely.
40 years from now why would people use Bitcoin over centralized
private banknotes like paypal or democratic government controlled
currencies?
Perhaps Bitcoin transaction could transition to being more of the
same=E2=80=94 controlled by a consortium of banks, exchanging gigabyte bloc=
ks
over terabit ethernet, but I think that would be sad. An alternative
which was autonomous and decentralized even if the transactions were
somewhat slow or costly would be excellent competition for everything
else, and it's something I think man kind ought to have.
|
