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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
|
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 15A7EA88
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 20:51:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
[209.85.213.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2406C281
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 20:51:47 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id r69so69471215vke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 13:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=vlDwJIMBKsbtp9dPqzTMUN3/jaM5JNvkWTWl2xwDNoY=;
b=A8NAR/dEoNTMgpMC8GV01+je9Nn9NaI/xnZX2g4GF36ulXJPlVZgnpaEyvFzMskg9S
/ppprwQ3RahgPN8PVUlqML0qF9YtceKpb9q896oeKf/pNh+lNHzsp1TfU4ysfY7Y0Jw+
mlLO2MTjl7E3cgv+SrCuP8KUg04oHW/HjgJH6VdiCtW3IuXxbzHoKgYXC+RVJb9eEzYT
rIF7POoJia7O5PprNtrlSlAPgdVsyHTH0BaPCyx2dRunjgfr1LRy91QoJGwNTj2w6Vjf
cCU3+FxPoZVLYdOrtnMSOh3ioeb2lNz9/k1hs6rXrHNd8CkRDbjrXzAVpw4KMJDhaeXT
xz6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=vlDwJIMBKsbtp9dPqzTMUN3/jaM5JNvkWTWl2xwDNoY=;
b=nEAX+hMFNC4Ffa+dOoNiymjiWDzfJjxmqcEX03ubQoNMM4We1rwcIfjhZALLK/caAz
f3Q0Bquv1Pv33xno4s2RZis448Fh4K53wKrwoXugj9mPBHq601caWcptkNIxxap8BjPw
IERcRz2rTgVYFCj8EPetzaEYd/qPF3KprHYJ5h+DFx4vYvzHzp8DCL3sP8hi7ugUHA62
NLLBwhHiA9ujlzDvArpu2g57smKPzWGSLngbjEgHN/VkUwwn8XbPFut80CyBzmdpZcU2
R2cAfqw/zE8OKV0Vpg4kIR/8iAb0hnB6vVtLJSmXtP1+cvACDq4nghnQ8VyvQJg8I3t9
JCHg==
X-Gm-Message-State: AFeK/H0VU93GcxSDre53twte9QItUvOP+mSihErMFHDr21rm/XdJmZ8fsKaXSK2IvaC0aNMZqXupevi4rQJTIg==
X-Received: by 10.31.164.198 with SMTP id n189mr929231vke.62.1490907106161;
Thu, 30 Mar 2017 13:51:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Thu, 30 Mar 2017 13:51:45 -0700 (PDT)
In-Reply-To: <1715389.dpD6Bbpm7b@strawberry>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
<2349f523-942c-ffb9-7af2-5cc81264888f@gmail.com>
<127281C1AA02374F8AAD9EE04FAE878A0218E8B825@STUDMail1.muad.local>
<1715389.dpD6Bbpm7b@strawberry>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Thu, 30 Mar 2017 13:51:45 -0700
Message-ID: <CAD1TkXs=jbkgYUGOo7PP38J8fKnLJ7GaaiJus3CBhpWMca8tow@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114158f074b9fd054bf8dc8f
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 30 Mar 2017 21:03:21 +0000
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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 Mar 2017 20:51:48 -0000
--001a114158f074b9fd054bf8dc8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> What we want is a true fee-market where the miner can decide to make a
block
> smaller to get people to pay more fees, because if we were to go to 16MB
> blocks in one go, the cost of the miner would go up, but his reward based
on
> fees will go down!
I agree in concept with everything you've said here, but I think there's a
frequent misconception that there's a certain level of miner payouts that
miners "deserve" and/or the opposite, that miners "deserve" as little as
possible. The 51% attacks that PoW's shields us from are relatively well
defined, which can be used to estimate the minimum amount of sustainable
fees for shielding. Beyond that minimum amount of fees, the best amount of
fees for every non-miner is the lowest.
Unfortunately miners could arbitrarily decide to limit blocksizes, and
there's little except relay restrictions that everyone else could do about
it. Fortunately miners so far have pushed for blocksize increases at least
as much as anyone else, though the future when Bitcoin adoption stabilizes
would be an unknown.
> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel th=
e
> need to pay fees.
FYI, I don't see this happening again ever, barring brief exceptions,
unless there was a sudden blocksize change, which ideally we'd avoid ever
happening. The stable average value of the transaction fee determines what
kind of business use-cases can be built using Bitcoin. An average fee of
$0.001 usd enables a lot more use cases than $0.10 average fees, and $50.00
average fees still have far more possible use cases than a $1000 average
fee. If fees stabilize low, use cases will spring up to fill the
blockspace, unless miners arbitraily seek to keep the fees above some level=
.
On Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev
> wrote:
> > The original post and the assorted limit proposals---lead me to
> > something I think is worth reiterating: assuming Bitcoin adoption
> > continues to grow at similar or accelerating rates, then eventually the
> > mempool is going to be filled with thousands of txs at all times whethe=
r
> > block limits are 1MB or 16MB
>
> This is hopefully true. :)
>
> There is an unbounded amount of demand for block space, and as such it
> doesn=E2=80=99t benefit anyone if the amount of free transactions get out=
of hand.
> Because freeloaders would definitely be able to completely suffocate
> Bitcoin.
>
> In the mail posted by OP he makes clear that this is a proposal for a har=
d
> fork to change the block size *limit*. The actual block size would not be
> changed at the same time, it will continue being set based on market valu=
es
> or whatever we decide between now and then.
>
> The block size itself should be set based on the amount of fees being pai=
d
> to miners to make a block.
>
> What we want is a true fee-market where the miner can decide to make a
> block
> smaller to get people to pay more fees, because if we were to go to 16MB
> blocks in one go, the cost of the miner would go up, but his reward based
> on
> fees will go down!
> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel th=
e
> need to pay fees.
>
> As such I don=E2=80=99t fear the situation where the block size limit goe=
s up a lot
> in one go, because it is not in anyone=E2=80=99s interest to make the act=
ual block
> size follow.
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114158f074b9fd054bf8dc8f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:12.8px">What we want is=
a true fee-market where the miner can decide to make a block</span><br sty=
le=3D"font-size:12.8px"><span style=3D"font-size:12.8px">> smaller to ge=
t people to pay more fees, because if we were to go to 16MB</span><br style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">> blocks in one g=
o, the cost of the miner would go up, but his reward based on</span><br sty=
le=3D"font-size:12.8px"><span style=3D"font-size:12.8px">> fees will go =
down!</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"=
><br>I agree in concept with everything you've said here, but I think t=
here's a frequent misconception that there's a certain level of min=
er payouts that miners "deserve" and/or the opposite, that miners=
"deserve" as little as possible.=C2=A0 The 51% attacks that PoW&=
#39;s shields us from are relatively well defined, which can be used to est=
imate the minimum amount of sustainable fees for shielding.=C2=A0 Beyond th=
at minimum amount of fees, the best amount of fees for every non-miner is t=
he lowest.<br><br>Unfortunately miners could arbitrarily decide to limit bl=
ocksizes, and there's little except relay restrictions that everyone el=
se could do about it.=C2=A0 Fortunately miners so far have pushed for block=
size increases at least as much as anyone else, though the future when Bitc=
oin adoption stabilizes would be an unknown.<br><br>> A block so big tha=
t 100% of the transactions will always be mined in the</span><br style=3D"f=
ont-size:12.8px"><span style=3D"font-size:12.8px">> next block will just=
cause a large section of people to no longer feel the</span><br style=3D"f=
ont-size:12.8px"><span style=3D"font-size:12.8px">> need to pay fees.<br=
><br>FYI, I don't see this happening again ever, barring brief exceptio=
ns, unless there was a sudden blocksize change, which ideally we'd avoi=
d ever happening.=C2=A0 The stable=C2=A0</span><span style=3D"font-size:12.=
8px">average=C2=A0</span><span style=3D"font-size:12.8px">value of the tran=
saction fee determines what kind of business use-cases can be built using B=
itcoin.=C2=A0 An average fee of $0.001 usd enables a lot more use cases tha=
n $0.10 average fees, and $50.00 average fees still have far more possible =
use cases than a $1000 average fee.=C2=A0 If fees stabilize low, use cases =
will spring up to fill the blockspace, unless miners arbitraily seek to kee=
p the fees above some level.</span></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bit=
coin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 30 March 201=
7 07:23:31 CEST Ryan J Martin via bitcoin-dev<br>
wrote:<br>
<span class=3D"">>=C2=A0 =C2=A0 =C2=A0 The original post and the assorte=
d limit proposals---lead me to<br>
> something I think is worth reiterating: assuming Bitcoin adoption<br>
> continues to grow at similar or accelerating rates, then eventually th=
e<br>
> mempool is going to be filled with thousands of txs at all times wheth=
er<br>
> block limits are 1MB or 16MB<br>
<br>
</span>This is hopefully true. :)<br>
<br>
There is an unbounded amount of demand for block space, and as such it<br>
doesn=E2=80=99t benefit anyone if the amount of free transactions get out o=
f hand.<br>
Because freeloaders would definitely be able to completely suffocate Bitcoi=
n.<br>
<br>
In the mail posted by OP he makes clear that this is a proposal for a hard<=
br>
fork to change the block size *limit*. The actual block size would not be<b=
r>
changed at the same time, it will continue being set based on market values=
<br>
or whatever we decide between now and then.<br>
<br>
The block size itself should be set based on the amount of fees being paid<=
br>
to miners to make a block.<br>
<br>
What we want is a true fee-market where the miner can decide to make a bloc=
k<br>
smaller to get people to pay more fees, because if we were to go to 16MB<br=
>
blocks in one go, the cost of the miner would go up, but his reward based o=
n<br>
fees will go down!<br>
A block so big that 100% of the transactions will always be mined in the<br=
>
next block will just cause a large section of people to no longer feel the<=
br>
need to pay fees.<br>
<br>
As such I don=E2=80=99t fear the situation where the block size limit goes =
up a lot<br>
in one go, because it is not in anyone=E2=80=99s interest to make the actua=
l block<br>
size follow.<br>
<span class=3D"im HOEnZb">--<br>
Tom Zander<br>
Blog: <a href=3D"https://zander.github.io" rel=3D"noreferrer" target=3D"_bl=
ank">https://zander.github.io</a><br>
Vlog: <a href=3D"https://vimeo.com/channels/tomscryptochannel" rel=3D"noref=
errer" target=3D"_blank">https://vimeo.com/channels/<wbr>tomscryptochannel<=
/a><br>
</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________=
__<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a114158f074b9fd054bf8dc8f--
|
