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
|
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 872EB323
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 21:05:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
[209.85.213.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2813EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Aug 2015 21:05:10 +0000 (UTC)
Received: by igbij6 with SMTP id ij6so35124820igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Aug 2015 14:05:10 -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=X5NH1uMBHJWTX8fVB/kGhzt+ZB3xL5GBMirAfT24igc=;
b=hxcLe0r/IeDmPpR1m2qAoqOdGq+V6bzPO5btDbuiKksw4N0FksbHrW7vsjc5GAnTcA
Bh/7OoYvK/XYcfeejcgz2D9LXGpVC8czEktArEwKhwUGeP8nyNjLQCxACIVyqLltGk5w
w0nYclyH47eMTTSCvxypIhRRG3ID1pHbb5OHRN2nvDiHw5Zn5ujNF7niN3n0bHZti9CE
EWQnBBoeAO4cYFo+vY/U+KuQ7TM35VH7nzRQvWFhQcHJKmMrtgVn5BzkX5WKAM2Hw2nf
Kqkq6O74bmraWEU05w4H2YpVensLmOeitDYHGq32SM2KfVSGruR6JURoBUlbpMtl+9lY
P7rw==
MIME-Version: 1.0
X-Received: by 10.50.93.69 with SMTP id cs5mr14936088igb.4.1438463110497; Sat,
01 Aug 2015 14:05:10 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Sat, 1 Aug 2015 14:05:10 -0700 (PDT)
In-Reply-To: <55BD2A7C.9060504@juno.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
<25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com>
<4608887.aSM42bDkNk@coldstorage>
<CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
<55BD2A7C.9060504@juno.com>
Date: Sat, 1 Aug 2015 23:05:10 +0200
Message-ID: <CAPg+sBg5fQZUfKn344xtFGUyUto-oCgBoYYWZpWi6uHUZ6Q6rQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: "John T. Winslow" <jtwinslow@juno.com>
Content-Type: multipart/alternative; boundary=089e01537ed8b94d4d051c464aa1
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: Sat, 01 Aug 2015 21:05:11 -0000
--089e01537ed8b94d4d051c464aa1
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the block size increase, at least conceptually it seems to me
> there should be an easy solution. If we look at what works well with
> bitcoin, for example the block reward halving and difficulty regimes which
> due to their step function nature both contribute to the stability and
> predictability of the bitcoin universe while still allowing for the
> necessary dynamic adjustments. It seems to me there should be a
> corresponding and equally simple solution for the maximum block size.
>
> I've never quite understood the supposed rationale behind the proposals
> for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be
> trivial to implement. Why not come up with an equally simple, predictable
> dynamic function consistent with what is already proven to work in the
> bitcoin universe that would both preserve the scarcity of transaction
> capacity to encourage a fee market but also allow for more transactions
> when needed.
>
I disagree with the notion of "needed". The blockchain provides utility at
every size, and perhaps more at some sizes than at other sizes, but any
finite size will permit some use cases and not others. This is already the
case and will remain the case. I think the "demand for payments" should be
considered infinite, and some of them will fit on a block chain and pay a
fee for it, and others will need to rely on more efficient, cheaper, but
higher trust systems. You can't use observed usage as a metric for demand
without fixing the cost.
I think available space should grow with technology, to keep the relative
costs to the ecosystem for maintaining a decentralized system constant.
That may or may not lead to a fee market, but I don't think the fee market
is a goal - only a healthy outcome. The goal is an ecosystem that accepts
that the limit to scalability is set by the requirements of a decentralized
system, and its demand - and certainly not perceived demand at potentially
near-zero fee/cost - can't change that.
> For example how about something like once every month at month-end, take
> the 6-month average non-zero transaction fee block size and multiply by 1.5?
>
>
That's trivially gamable by miners, by filling the blocks with their own
transactions.
--
Pieter
--089e01537ed8b94d4d051c464aa1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitco=
in-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Regarding the block size increase, at
least conceptually it seems to me there should be an easy
solution. If we look at what works well with bitcoin, for example
the block reward halving and difficulty regimes which due to their
step function nature both contribute to the stability and
predictability of the bitcoin universe while still allowing for
the necessary dynamic adjustments. It seems to me there should be
a corresponding and equally simple solution for the maximum block
size.<br>
<br>
I've never quite understood the supposed rationale behind the
proposals for a new static maximum of 20 MB or 8 MB or 2 MB other
than it would be trivial to implement. Why not come up with an
equally simple, predictable dynamic function consistent with what
is already proven to work in the bitcoin universe that would both
preserve the scarcity of transaction capacity to encourage a fee
market but also allow for more transactions when needed.<br></div></d=
iv></blockquote><div><br></div><div>I disagree with the notion of "nee=
ded". The blockchain provides utility at every size, and perhaps more =
at some sizes than at other sizes, but any finite size will permit some use=
cases and not others. This is already the case and will remain the case. I=
think the "demand for payments" should be considered infinite, a=
nd some of them will fit on a block chain and pay a fee for it, and others =
will need to rely on more efficient, cheaper, but higher trust systems. You=
can't use observed usage as a metric for demand without fixing the cos=
t.<br><br></div><div>I think available space should grow with technology, t=
o keep the relative costs to the ecosystem for maintaining a decentralized =
system constant. That may or may not lead to a fee market, but I don't =
think the fee market is a goal - only a healthy outcome. The goal is an eco=
system that accepts that the limit to scalability is set by the requirement=
s of a decentralized system, and its demand - and certainly not perceived d=
emand at potentially near-zero fee/cost - can't change that.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"=
><div>
<br>
For example how about something like once every month at
month-end, take the 6-month average non-zero transaction fee block
size and multiply by 1.5?<br>
<br></div></div></blockquote><div><br></div><div>That's trivially=
gamable by miners, by filling the blocks with their own transactions.<br><=
br>-- <br></div><div>Pieter<br><br></div></div></div></div>
--089e01537ed8b94d4d051c464aa1--
|
