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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BBE44267
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 12:50:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E827510A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 12:50:46 +0000 (UTC)
Received: by ioea135 with SMTP id a135so52348443ioe.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 05:50:46 -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=3C12qYpyOJ9t2AG4NRZZH9lMJ6o9OVXLU5mSeRFMN78=;
b=dAgzy5K4hJHNmVG5tNRx9T2cQmSc9zzIbyNsxkFS3zY3JeEXnYAQ468x1YspNkeJVs
o2FHf2KhZV08gVD1mx6U3UUkTIMjYkUFnCCsBkpC0tuhBVR6gRBlk0ujycuGY8/Ox1lM
XnN3C5AuNIocmW2fNlneQJohr9JPORhSvhBboTOUhTzDGtR3ZpoLBZ/Adoy0x9LVVDxN
RU3a15EwxwiwjXSHrnvGB4/lajCqaQgg8Du+XIWfEZYJIKNaLqBnFzEXloDtZ40zCAJv
QGmypr2oZd/mfxyF3VLCDbPzI74J/vKWcTLtQqtPy6fBJ29mGrSDEOE3MP6TpkSyzdnf
OQ1Q==
MIME-Version: 1.0
X-Received: by 10.107.9.137 with SMTP id 9mr10418117ioj.50.1438260646463; Thu,
30 Jul 2015 05:50:46 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 05:50:46 -0700 (PDT)
In-Reply-To: <F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
<55B94FAD.7040205@mail.bihthai.net>
<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
Date: Thu, 30 Jul 2015 14:50:46 +0200
Message-ID: <CAPg+sBjsQPUZEj0LFHBWuM4E+4SsUu4C9fcb7OJX4SC4+omvPQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f8f14ed5033051c17263f
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't
temporary
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 12:50:47 -0000
--001a113f8f14ed5033051c17263f
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think that given
> what we now today about the Bitcoin network, increasing block size
> externalizes costs in dangerous ways. Remember that total cost includes not
> just equipment costs but also things like block propagation latency and
> specifically identified security risks. Some of these security risks were
> only appreciated relatively recently and were completely unknown in 2009.
>
> I would like (and have been asking) those people to take the time to
> quantify those costs and write up those risks in a careful way.
>
> I believe the costs and risks of 8MB blocks are minimal, and that the
> benefits of supporting more transaction FAR outweigh those costs and risks,
> but it is hard to have a rational conversation about that when even simple
> questions like 'what is s reasonable cost to run a full node' are met with
> silence.
>
I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
(even assuming miners actually produce 8 MB blocks). There are very few use
cases that Bitcoin on-chain can support with a small extra factor. I think
the market will grow to adapt to whatever is offered anyway.
Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.
Wanting to increase the scale of the system is in conflict with all of
those. Attempting to buy time with a fast increase is not wanting to face
that reality, and treating the system as something whose scale trumps all
other concerns. A long term scalability plan should aim on decreasing the
need for trust required in off-chain systems, rather than increasing the
need for trust in Bitcoin.
Making controversial changes to the network, and not wanting to face the
reality that block chain space is a finite resource - whether enforced by a
consensus rule or by miner's capacity to process transactions - is a huge
treat to Bitcoin's usefulness in the long term.
I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".
Let's scale the block size gradually over time, according to technological
growth.
--
Pieter
--001a113f8f14ed5033051c17263f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <sp=
an dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wro=
te:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span class=3D"">
<br>
> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:<br>
><br>
> and a number of the people most intimately familiar with the inner wor=
kings of the system (some of whom are in this thread) think that given what=
we now today about the Bitcoin network, increasing block size externalizes=
costs in dangerous ways. Remember that total cost includes not just equipm=
ent costs but also things like block propagation latency and specifically i=
dentified security risks. Some of these security risks were only appreciate=
d relatively recently and were completely unknown in 2009.<br>
<br>
</span>I would like (and have been asking) those people to take the time to=
quantify those costs and write up those risks in a careful way.<br>
<br>
I believe the costs and risks of 8MB blocks are minimal, and that the benef=
its of supporting more transaction FAR outweigh those costs and risks, but =
it is hard to have a rational conversation about that when even simple ques=
tions like 'what is s reasonable cost to run a full node' are met w=
ith silence.<br></blockquote><div><br></div>I think the benefit of an 8 MB =
over a 1 MB in terms of utility is marginal (even assuming miners actually =
produce 8 MB blocks). There are very few use cases that Bitcoin on-chain ca=
n support with a small extra factor. I think the market will grow to adapt =
to whatever is offered anyway.<br><br>Bitcoin's advantage over other sy=
stems does not lie in scalability.=20
Well-designed centralized systems can trivially compete with Bitcoin's=
=20
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in=20
network peers, miners, and those who influence or control the system.=20
Wanting to increase the scale of the system is in conflict with all of=20
those. Attempting to buy time with a fast increase is not wanting to=20
face that reality, and treating the system as something whose scale=20
trumps all other concerns. A long term scalability plan should aim on=20
decreasing the need for trust required in off-chain systems, rather than
increasing the need for trust in Bitcoin.<br><br></div><div class=3D"gmail=
_quote">Making controversial changes to the network, and not wanting to fac=
e the reality that block chain space is a finite resource - whether enforce=
d by a consensus rule or by miner's capacity to process transactions - =
is a huge treat to Bitcoin's usefulness in the long term.<br><br></div>=
<div class=3D"gmail_quote">I think the risks of trying to make a controvers=
ial change to the network FAR outweighs the benefits of a small constant fa=
ctor that "kicks the can down the road".<br><br></div><div class=
=3D"gmail_quote">Let's scale the block size gradually over time, accord=
ing to technological growth.<br><br>-- <br></div><div class=3D"gmail_quote"=
>Pieter<br><br></div></div></div>
--001a113f8f14ed5033051c17263f--
|
