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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Yy1hh-00028F-Ge
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:34:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yy1hg-0001E1-Bd
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:34:49 +0000
Received: by wgv5 with SMTP id 5so42621105wgv.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 10:34:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.9.161 with SMTP id a1mr7285438wjb.39.1432834482378; Thu,
28 May 2015 10:34:42 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 10:34:42 -0700 (PDT)
In-Reply-To: <CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
Date: Thu, 28 May 2015 19:34:42 +0200
X-Google-Sender-Auth: -pek2aHpQqLLhgbBCbFdkEPTfEw
Message-ID: <CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b5d34fa581ebf051727c610
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yy1hg-0001E1-Bd
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 17:34:49 -0000
--047d7b5d34fa581ebf051727c610
Content-Type: text/plain; charset=UTF-8
>
> Twenty is scary.
>
To whom? The only justification for the max size is DoS attacks, right?
Back when Bitcoin had an average block size of 10kb, the max block size was
100x the average. Things worked fine, nobody was scared.
The max block size is really a limit set by hardware capability, which is
something that's difficult to measure in software. I think I preferred your
original formula that guesstimated based on previous trends to one that
just tries to follow some average.
As noted, many miners just accept the defaults. With your proposed change
their target would effectively *drop* from 1mb to 800kb today, which seems
crazy. That's the exact opposite of what is needed right now.
I am very skeptical about this idea.
> I don't think us developers should be deciding things like whether or not
> fees are too high, too low,
>
Miners can already attempt to apply fee pressure by just not mining
transactions that they feel don't pay enough. Some sort of auto-cartel that
attempts to restrict supply based on everyone looking at everyone else
feels overly complex and prone to strange situations: it looks a lot like
some kind of Mexican standoff to me.
Additionally, the justification for the block size limit was DoS by someone
mining "troll blocks". It was never meant to be about fee pressure.
Resource management inside Bitcoin Core is certainly something to be
handled by developers.
--047d7b5d34fa581ebf051727c610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Twenty is scary.</=
div></div></blockquote><div><br></div><div>To whom? The only justification =
for the max size is DoS attacks, right? Back when Bitcoin had an average bl=
ock size of 10kb, the max block size was 100x the average. Things worked fi=
ne, nobody was scared.</div><div><br></div><div>The max block size is reall=
y a limit set by hardware capability, which is something that's difficu=
lt to measure in software. I think I preferred your original formula that g=
uesstimated based on previous trends to one that just tries to follow some =
average.</div><div><br></div><div>As noted, many miners just accept the def=
aults. With your proposed change their target would effectively <b>drop</b>=
=C2=A0from 1mb to 800kb today, which seems crazy. That's the exact oppo=
site of what is needed right now.</div><div><br></div><div>I am very skepti=
cal about this idea.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra">I don't think us developers should be deci=
ding things like whether or not fees are too high, too low,</div></div></bl=
ockquote><div><br></div><div>Miners can already attempt to apply fee pressu=
re by just not mining transactions that they feel don't pay enough. Som=
e sort of auto-cartel that attempts to restrict supply based on everyone lo=
oking at everyone else feels overly complex and prone to strange situations=
: it looks a lot like some kind of Mexican standoff to me.</div><div><br></=
div><div>Additionally, the justification for the block size limit was DoS b=
y someone mining "troll blocks". It was never meant to be about f=
ee pressure. Resource management inside Bitcoin Core is certainly something=
to be handled by developers.<br></div></div></div></div>
--047d7b5d34fa581ebf051727c610--
|
