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
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C1BE9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 22:30:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12E94164
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 22:30:35 +0000 (UTC)
Received: by mail-ua0-f175.google.com with SMTP id 51so66428552uai.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 14:30:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=3alfcpPF6DDf1vGhMsb6a58Bae/HEQRUtffR2DMOHLQ=;
b=FUyz+lpq6LfkjOzCeI3EqvWLVXSM7dfUgOx04QyhjL13n0jfR4ehYgoy+BTerAOvj/
1ckZG0LwxeGzS5y6YVlsT4KQfYjh1Th7B2jU/70bme/Ve58FeAOZ2RdyHqlGPzlIG6Ng
ZPdQIZ2ZQ8g6HZwNgQy38Ra75NoqfTiHS0dWc5Lnh0ikJ7v0ki94begZH6WNjFsIE3yW
UFLeUA44BOtTLp75dLVfQWI03Hw/40873li11C4rmm5oOj81vCnHs/1pRJ2UlolffmwJ
zuBIUUtr5T63NiYttdts5g3Wp29RidSj+PMM1T6OURJoRZzt7b7hVMtuphCp4H6l3E+w
8tQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=3alfcpPF6DDf1vGhMsb6a58Bae/HEQRUtffR2DMOHLQ=;
b=IG7FMqVvbzG1v0epFlKJ648UnhBIIIMsUafs06B1MgWXCnFfVAhNSX46tdjnJ0UBpL
Lf8opVejlRyeBaWUKFUOSsoTW3tPYRYdPN9yP6MVqkeoRSmkYtnlgNtWK6zhm8JcNnvq
HeF/+D5QXBApMRAKSl3Ib5jdRdBrC+CCvV7TAs+YLJCzDLY0Fg0tJM0BpmbGJ2Ewotj9
U/38V6SRl0iCNYF6bzioYMAUX3r/l+Cgo23CoBePfk9KC2GQ7d450DveU7+ucXOhR6Cf
2uR/X6QaO2SEeImjv73NKbnSPHDnsgTGcrESYCaCP9C3FAJsRj1qsLc+zRl79+rrF4gQ
fFPQ==
X-Gm-Message-State: AKaTC01Dp9GPnqlM+TR8STqwmdSP7HF4SamHbPx5AhJOLnPjEr2X/vAlOn/hxnepC1vr8itHlIOuzrWIkbUgPw==
X-Received: by 10.176.6.233 with SMTP id g96mr69310111uag.97.1481495435223;
Sun, 11 Dec 2016 14:30:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Sun, 11 Dec 2016 14:30:34 -0800 (PST)
In-Reply-To: <CADvTj4qSeASzHPNnFaBs8bAogDfLvnzLzgEPgbX0YX-VnN89aA@mail.gmail.com>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
<d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
<CAGCNRJo_VE9nBhP=oY7hV0UJ-OSuTBxu+Tf28_utJW8qi7rzxg@mail.gmail.com>
<CADvTj4rC6OyCFCwpExRdRF_ZVU_ONjtb3PycR3T_fkm6d=b_Wg@mail.gmail.com>
<CAGCNRJqEVo6cMOLeENNue3=2mAHnWL2ViUKXVXAke_W0CXKKEg@mail.gmail.com>
<CADvTj4qSeASzHPNnFaBs8bAogDfLvnzLzgEPgbX0YX-VnN89aA@mail.gmail.com>
From: "t. khan" <teekhan42@gmail.com>
Date: Sun, 11 Dec 2016 17:30:34 -0500
Message-ID: <CAGCNRJpy+5d5mNRevzmssU791du+=ZJ6ougti0LyVXpc663FMg@mail.gmail.com>
To: James Hilliard <james.hilliard1@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c04515c272704054369893b
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
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: Sun, 11 Dec 2016 22:30:36 -0000
--94eb2c04515c272704054369893b
Content-Type: text/plain; charset=UTF-8
The assumption you're making is incorrect. There is not an infinite number
of low-fee transactions.
Yes, the average fee will go down compared to today with Block75, but this
will balance itself between demand and the minimum fee miners are willing
to accept (not zero).
For example, add 200kb to today's max block size. How does that affect fees?
(200kb would likely be the first increase if Block75 activated today)
-t.k.
On Sun, Dec 11, 2016 at 4:55 PM, James Hilliard <james.hilliard1@gmail.com>
wrote:
> I think the main thing you're missing is that there will always be
> transactions available to mine simply because demand for blockspace is
> effectively unbounded as fees approach 0. Nodes generally have a
> static mempool size and dynamic minrelaytxfee nowadays so as
> transactions get mined lower fee transactions get accepted into the
> mempool. An individual opting to not send a transaction would not make
> the blocks smaller simply because there will always be other
> transactions available(it would really only have an effect on the
> transaction fees needed to get mined).
>
> On Sun, Dec 11, 2016 at 3:40 PM, t. khan <teekhan42@gmail.com> wrote:
> >
> > On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <
> james.hilliard1@gmail.com>
> > wrote:
> >>
> >> What's most likely to happen is miners will max out the blocks they
> >> mine simply to try and get as many transaction fees as possible like
> >> they are doing right now(there will be a backlog of transactions at
> >> any block size). Having the block size double every year would likely
> >> cause major problems and this proposal allows over a 7x increase it
> >> seems.
> >
> >
> > Block75 is not exponential scaling. It's true the max theoretical
> increase
> > in the first year would be 7x, but the next year would be a max of 2x,
> and
> > the next could only increase by 50% and so on.
> >
> > However, to reach the max in the first year: 1) ALL blocks would have to
> be
> > 100% full and 2) transactions would have to increase at the same rate.
> We'd
> > have to be doing 2.1 million transactions a day within a year to make
> that
> > happen, and would therefore need blocks to be that big.
> >
> > Realistically, max block size will grow (and shrink) at a much slower
> rate
> > ... even more so with SegWit.
> >
> >>
> >> The main problem with this proposal I think is that users effectively
> >>
> >> have no way to stop the miners from increasing block size
> >> continuously.
> >
> >
> > Yes they could, simply by not sending transactions. Users don't care at
> all
> > about block size. They just want their transactions to be fast and
> > relatively cheap.
> >
> > -t.k.
>
--94eb2c04515c272704054369893b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The assumption you're making is incorrect. There is no=
t an infinite number of low-fee transactions.<div><br></div><div>Yes, the a=
verage fee will go down compared to today with Block75, but this will balan=
ce itself between demand and the minimum fee miners are willing to accept (=
not zero).</div><div><br></div><div>For example, add 200kb to today's m=
ax block size. How does that affect fees?</div><div>(200kb would likely be =
the first increase if Block75 activated today)</div><div><br></div><div>-t.=
k.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Sun, Dec 11, 2016 at 4:55 PM, James Hilliard <span dir=3D"ltr"><<a href=
=3D"mailto:james.hilliard1@gmail.com" target=3D"_blank">james.hilliard1@gma=
il.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">I think the =
main thing you're missing is that there will always be<br>
transactions available to mine simply because demand for blockspace is<br>
effectively unbounded as fees approach 0. Nodes generally have a<br>
static mempool size and dynamic minrelaytxfee nowadays so as<br>
transactions get mined lower fee transactions get accepted into the<br>
mempool. An individual opting to not send a transaction would not make<br>
the blocks smaller simply because there will always be other<br>
transactions available(it would really only have an effect on the<br>
transaction fees needed to get mined).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Sun, Dec 11, 2016 at 3:40 PM, t. khan <<a href=3D"mailto:teekhan42@gm=
ail.com">teekhan42@gmail.com</a>> wrote:<br>
><br>
> On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <<a href=3D"mailto:=
james.hilliard1@gmail.com">james.hilliard1@gmail.com</a>><br>
> wrote:<br>
>><br>
>> What's most likely to happen is miners will max out the blocks=
they<br>
>> mine simply to try and get as many transaction fees as possible li=
ke<br>
>> they are doing right now(there will be a backlog of transactions a=
t<br>
>> any block size). Having the block size double every year would lik=
ely<br>
>> cause major problems and this proposal allows over a 7x increase i=
t<br>
>> seems.<br>
><br>
><br>
> Block75 is not exponential scaling. It's true the max theoretical =
increase<br>
> in the first year would be 7x, but the next year would be a max of 2x,=
and<br>
> the next could only increase by 50% and so on.<br>
><br>
> However, to reach the max in the first year: 1) ALL blocks would have =
to be<br>
> 100% full and 2) transactions would have to increase at the same rate.=
We'd<br>
> have to be doing 2.1 million transactions a day within a year to make =
that<br>
> happen, and would therefore need blocks to be that big.<br>
><br>
> Realistically, max block size will grow (and shrink) at a much slower =
rate<br>
> ... even more so with SegWit.<br>
><br>
>><br>
>>=C2=A0 The main problem with this proposal I think is that users ef=
fectively<br>
>><br>
>> have no way to stop the miners from increasing block size<br>
>> continuously.<br>
><br>
><br>
> Yes they could, simply by not sending transactions. Users don't ca=
re at all<br>
> about block size. They just want their transactions to be fast and<br>
> relatively cheap.<br>
><br>
> -t.k.<br>
</div></div></blockquote></div><br></div>
--94eb2c04515c272704054369893b--
|
