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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ryanxcharles@gmail.com>) id 1YtoMJ-0001gz-0D
for bitcoin-development@lists.sourceforge.net;
Sun, 17 May 2015 02:31:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.46 as permitted sender)
client-ip=209.85.220.46; envelope-from=ryanxcharles@gmail.com;
helo=mail-pa0-f46.google.com;
Received: from mail-pa0-f46.google.com ([209.85.220.46])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YtoMH-0001st-EZ
for bitcoin-development@lists.sourceforge.net;
Sun, 17 May 2015 02:31:18 +0000
Received: by pabru16 with SMTP id ru16so90979269pab.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 May 2015 19:31:11 -0700 (PDT)
X-Received: by 10.68.206.7 with SMTP id lk7mr31614658pbc.52.1431829871660;
Sat, 16 May 2015 19:31:11 -0700 (PDT)
Received: from ?IPv6:2601:9:4680:dd0:d193:4b1c:eda4:2786?
([2601:9:4680:dd0:d193:4b1c:eda4:2786])
by mx.google.com with ESMTPSA id fp3sm5931233pdb.52.2015.05.16.19.31.09
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 16 May 2015 19:31:10 -0700 (PDT)
Message-ID: <5557FD6E.2050903@gmail.com>
Date: Sat, 16 May 2015 19:31:10 -0700
From: "Ryan X. Charles" <ryanxcharles@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tom Harding <tomh@thinlink.com>, bitcoin-development@lists.sourceforge.net
References: <5554BDC1.6070206@thinlink.com>
In-Reply-To: <5554BDC1.6070206@thinlink.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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
(ryanxcharles[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: 1YtoMH-0001st-EZ
Subject: Re: [Bitcoin-development] No Bitcoin For You
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: Sun, 17 May 2015 02:31:19 -0000
I agree with this analysis. I'm not sure if we will increase 1 MB
block size or not, but with a block size that small, it is all but
impossible for most people on the planet to ever own even a single utxo.
At 7tps, how long would it take to give 1 utxo to all of the 7 billion
people currently alive? It would take 1 billion seconds, or about 32
years.[1] So for all practical purposes, at 1 MB block size, far less
than 1% of people will ever be able to own even a single satoshi.
Unless those people are willing to wait around 30 years for their
lightning network to settle, they will either not use bitcoin, or they
will use a substitute (such as a parallel decentralized network, or a
centralized service) that lacks the full trust-minimized security
guarantees of the main bitcoin blockchain.
I can't speak for most people, but for me personally, the thing I care
most about as an individual (besides being able to send bitcoin to and
from anyone on the planet) is being able to validate the blockchain.
With a pruning node, this means I need to download the blockchain one
time (not store it), and maintain the utxo set. The utxo set is,
roughly speaking, 30 bytes per utxo, and therefore, at one utxo per
person, about 7*30 billion bytes, or 210 GB. That's very achievable on
the hardware of today. Of course, some individuals or companies will
have far more than one utxo. Estimating an average of ten utxos per
person, that will be 2.1 TB. Also very achievable on the hardware of
today.
I don't think every transaction in the world should be on the
blockchain, but I think it should be able to handle (long-term) enough
transactions that everyone can have their transactions settled on a
timescale suitable for human life. 30 years is unsuitable, but 1 day
would be pretty good. It would be great if I could send trillions of
transactions per day on networks built on top of bitcoin, and have my
transactions settle on the actual blockchain once per day. This means
we would need to support about 1 utxo per person per day, or 7 billion
transactions per day. That translates to about 81 thousand
transactions per second [2], or approximately 10,000 times the current
rate. That would be 10 GB per ten minutes, which is achievable on
current hardware (albeit not yet inexpensively).
Using SPV security rather than pruning security makes the cost even
lower. A person relying on SPV would not have to download every 10 GB
block, but only their transactions (or a small superset of them),
which is already being done - scaling to 7 billion people would not
require that SPV nodes perform any more computation than they already
do. Nonetheless, I think pruning should be considered the default
minimum, since that it what is required to get the full
trust-minimized security guarantees of the blockchain. And that
requires 10 GB blocks (or thereabouts).
The number of people on the planet will also grow, perhaps to 14
billion people in the next few decades. However, the estimates here
would still be roughly correct. 10 GB blocks, or approximately so,
allows everyone in the world to have their transactions settled on the
blockchain in a timely manner, whereas 1 MB blocks do not. And this is
already achievable on current hardware. The most significant cost is
bandwidth, but that will probably become substantially less expensive
in the coming years, making it possible for everyone to inexpensively
and securely send and receive bitcoin to anyone else, without having
to use a parallel network with reduced security or rely on trusted
third parties.
[1] 10^9 / 60 / 60 / 24 / 365 ~= 32.
[2] 7*10^9 / 24 / 60 / 60 ~= 81018
On 05/14/2015 08:22 AM, Tom Harding wrote:
> A recent post, which I cannot find after much effort, made an
> excellent point.
>
> If capacity grows, fewer individuals would be able to run full
> nodes. Those individuals, like many already, would have to give up
> running a full-node wallet :(
>
> That sounds bad, until you consider that the alternative is running
> a full node on the bitcoin 'settlement network', while massive
> numbers of people *give up any hope of directly owning bitcoin at
> all*.
>
> If today's global payments are 100Ktps, and move to the Lightning
> Network, they will have to be consolidated by a factor of 25000:1
> to fit into bitcoin's current 4tps capacity as a settlement
> network. You executing a personal transaction on that network will
> be about as likely as you personally conducting a $100 SWIFT
> transfer to yourself today. For current holders, just selling or
> spending will get very expensive!
>
> Forcing block capacity to stay small, so that individuals can run
> full nodes, is precisely what will force bitcoin to become a
> backbone that is too expensive for individuals to use. I can't
> avoid the conclusion that Bitcoin has to scale, and we might as
> well be thinking about how.
>
> There may be a an escape window. As current trends continue toward
> a landscape of billions of SPV wallets, it may still be possible
> for individuals collectively to make up the majority of the
> network, if more parts of the network itself rely on SPV-level
> security.
>
> With SPV-level security, it might be possible to implement a
> scalable DHT-type network of nodes that collectively store and
> index the exhaustive and fast-growing corpus of transaction
> history, up to and including currently unconfirmed transactions.
> Each individual node could host a slice of the transaction set with
> a configurable size, let's say down to a few GB today.
>
> Such a network would have the desirable property of being run by
> the community. Most transactions would be submitted to it, and
> like today's network, it would disseminate blocks (which would be
> rapidly torn apart and digested). Therefore miners and other full
> nodes would depend on it, which is rather critical as those nodes
> grow closer to data-center proportions.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
>
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Ryan X. Charles
Software Engineer @BitGo
twitter.com/ryanxcharles
github.com/ryanxcharles
keybase.io/ryanxcharles
onename.com/ryanxcharles
|
