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
|
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 58D648D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 14:53:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E5E98EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Aug 2015 14:53:29 +0000 (UTC)
Received: by iodb91 with SMTP id b91so23530219iod.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Aug 2015 07:53:29 -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=mLm0vxkxsi/DCq6ve3Ak0WXGshEZsNnn/rVHAr3FTeM=;
b=TgDVN6M03GMVAUwA+Z0/QeXsSKDqXfoYQe04bY7PksMR8GS3lxv9gpA1hS+d6iUHWK
A8RCngFzCi28eKgLOXW4T+pkP5/4SCUKJRwj1GBa/aa/g0C8kLcMKdleO1AeUXwj6yNq
Yk1T3tqkdNGL+roCgmupez7Ei0x3F3OyfAEDrxHMOZ+dWdLDQxWnmKelUvDoKRryHnPa
Zc8ME4feS4h44Jn/gkXXGv7Bj2Xx4qjvaI9Ks2pwfkyBYUfR8OLKquypEb5x4MP4xjpi
18TOWmRFFMe/LsQEHBwjo69xKvSzzSrwUi0H4ecFS6ox4ZzFVTAHTE60q7XaVtVj8IbV
EUmg==
MIME-Version: 1.0
X-Received: by 10.107.9.137 with SMTP id 9mr2639286ioj.50.1438872809248; Thu,
06 Aug 2015 07:53:29 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 6 Aug 2015 07:53:29 -0700 (PDT)
In-Reply-To: <CABsx9T0QP3bmUkOSaD9X7zhcV3BNwT3xFZcsZnk+JL5oz-EfsA@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CABm2gDpp5+hkHmd6op6PPW658siKoEMRDfTWiEHHM7vJSLDhyA@mail.gmail.com>
<CA+BnGuFNOjzLaiPPnUSi-rkU94UMgmP30Si8N3oBSYG0q8j-_w@mail.gmail.com>
<CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
<CABsx9T22KUcbRb4ZfRDikbxK05pqWY1=uvYo10toWA-JwGa-PQ@mail.gmail.com>
<CAPg+sBg-KN5=A5_Fx3fo0dcD6mAdMUXBMNzW52SkQsRbADTmSg@mail.gmail.com>
<CABsx9T0QP3bmUkOSaD9X7zhcV3BNwT3xFZcsZnk+JL5oz-EfsA@mail.gmail.com>
Date: Thu, 6 Aug 2015 16:53:29 +0200
Message-ID: <CAPg+sBi-Ls3Kuk=KE5EApqCh8amkGTUEs9a-jh--vVXs4PtxCQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f8f14ac1ec4051ca5ae86
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] Block size following technological growth
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, 06 Aug 2015 14:53:30 -0000
--001a113f8f14ac1ec4051ca5ae86
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you do
>> believe that evolving towards an ecosystem where there is competition for
>> block space is a bad thing, right?
>>
>
> No, competition for block space is good.
>
So if we would have 8 MB blocks, and there is a sudden influx of users (or
settlement systems, who serve much more users) who want to pay high fees
(let's say 20 transactions per second) making the block chain inaccessible
for low fee transactions, and unreliable for medium fee transactions (for
any value of low, medium, and high), would you be ok with that? If so, why
is 8 MB good but 1 MB not? To me, they're a small constant factor that does
not fundamentally improve the scale of the system. I dislike the outlook of
"being forever locked at the same scale" while technology evolves, so my
proposal tries to address that part. It intentionally does not try to
improve a small factor, because I don't think it is valuable.
What is bad is artificially limiting or centrally controlling the supply of
> that space.
>
It's exactly as centrally limited as the finite supply of BTC - by
consensus. You and I may agree that a finite supply is a good thing, and
may disagree about whether a consensus rule about the block size is a good
idea (and if so, at what level), but it's a choice we make as a community
about the rules of the system we want to use.
--
Pieter
--001a113f8f14ac1ec4051ca5ae86
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <span dir=
=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
avinandresen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote">On T=
hu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <span dir=3D"ltr"><<a href=3D=
"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>But you seem t=
o consider that a bad thing. Maybe saying that you're claiming that thi=
s equals Bitcoin failing is an exaggeration, but you do believe that evolvi=
ng towards an ecosystem where there is competition for block space is a bad=
thing, right?<br></div></blockquote></div><div class=3D"gmail_extra"><br><=
/div></span><div class=3D"gmail_extra">No, competition for block space is g=
ood.</div></div></div></blockquote><div><br></div><div>So if we would have =
8 MB blocks, and there is a sudden influx of users (or settlement systems, =
who serve much more users) who want to pay high fees (let's say 20 tran=
sactions per second) making the block chain inaccessible for low fee transa=
ctions, and unreliable for medium fee transactions (for any value of low, m=
edium, and high), would you be ok with that? If so, why is 8 MB good but 1 =
MB not? To me, they're a small constant factor that does not fundamenta=
lly improve the scale of the system. I dislike the outlook of "being f=
orever locked at the same scale" while technology evolves, so my propo=
sal tries to address that part. It intentionally does not try to improve a =
small factor, because I don't think it is valuable.<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_extra">What is bad is artificially limiting or centrally cont=
rolling the supply of that space.</div></div></div></blockquote><div><br></=
div><div>It's exactly as centrally limited as the finite supply of BTC =
- by consensus. You and I may agree that a finite supply is a good thing, a=
nd may disagree about whether a consensus rule about the block size is a go=
od idea (and if so, at what level), but it's a choice we make as a comm=
unity about the rules of the system we want to use.<br><br></div><div>-- <b=
r></div><div>Pieter<br><br></div></div></div></div>
--001a113f8f14ac1ec4051ca5ae86--
|
