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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Yy1FF-0004Ef-GP
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:05:25 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yy1FE-0001gE-F0
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:05:25 +0000
Received: by wicmx19 with SMTP id mx19so129880992wic.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 10:05:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.99.69 with SMTP id eo5mr6323536wib.92.1432832718463;
Thu, 28 May 2015 10:05:18 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Thu, 28 May 2015 10:05:18 -0700 (PDT)
In-Reply-To: <CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
Date: Thu, 28 May 2015 19:05:18 +0200
X-Google-Sender-Auth: QXn0vz8y9Bt0u-melqUTTd5Fuxg
Message-ID: <CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04428fcc34e8700517275d71
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: 1Yy1FE-0001gE-F0
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:05:25 -0000
--f46d04428fcc34e8700517275d71
Content-Type: text/plain; charset=UTF-8
>
> Even a 2x rule (implying 800K max blocks) would, today, be squeezing out
> transactions / putting pressure to increase fees .....
>
> So my straw-man proposal would be: max size 2x average size over last 144
> blocks, calculated at every block.
>
Isn't that a step backwards, then? I see no reason for fee pressure to
exist at the moment. All it's doing is turning away users for no purpose:
mining isn't supported by fees, and the tiny fees we use right now seem to
be good enough to stop penny flooding.
Why not set the max size to be 20x the average size? Why 2x, given you just
pointed out that'd result in blocks shrinking rather than growing.
--f46d04428fcc34e8700517275d71
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:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>Even a 2x rule (implying 800K max blocks) would=
, today, be squeezing out transactions / putting pressure to increase fees =
.....=C2=A0</div><div><br></div><div>So my straw-man proposal would be: =C2=
=A0max size 2x average size over last 144 blocks, calculated at every block=
.<br></div></div></div></div></blockquote><div><br></div><div>Isn't tha=
t a step backwards, then? I see no reason for fee pressure to exist at the =
moment. All it's doing is turning away users for no purpose: mining isn=
't supported by fees, and the tiny fees we use right now seem to be goo=
d enough to stop penny flooding.</div><div><br></div><div>Why not set the m=
ax size to be 20x the average size? Why 2x, given you just pointed out that=
'd result in blocks shrinking rather than growing.</div></div></div></d=
iv>
--f46d04428fcc34e8700517275d71--
|
