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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ricardojdfilipe@gmail.com>) id 1YzNvb-0002UG-Im
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 11:30:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.174 as permitted sender)
client-ip=209.85.213.174;
envelope-from=ricardojdfilipe@gmail.com;
helo=mail-ig0-f174.google.com;
Received: from mail-ig0-f174.google.com ([209.85.213.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzNvZ-0007l9-Or
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 11:30:47 +0000
Received: by igbpi8 with SMTP id pi8so58544427igb.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 04:30:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.170.219 with SMTP id g88mr26356956ioj.85.1433158240432;
Mon, 01 Jun 2015 04:30:40 -0700 (PDT)
Received: by 10.36.20.207 with HTTP; Mon, 1 Jun 2015 04:30:40 -0700 (PDT)
In-Reply-To: <CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@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>
<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
<CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
<CA+VAk3O7SmDkxL9rATWe9oqCVVKcT=cFXDJnARPN8pv=UiHaiA@mail.gmail.com>
<CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@mail.gmail.com>
Date: Mon, 1 Jun 2015 12:30:40 +0100
Message-ID: <CALC81CNidPEgLpTVCRWqXYn0UpSCU-nuo5S85NSQ4UCce=n4EA@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.4 (/)
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
(ricardojdfilipe[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
-2.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YzNvZ-0007l9-Or
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: Mon, 01 Jun 2015 11:30:47 -0000
I've been following the discussion of the block size limit and IMO it
is clear that any constant block size limit is, as many have said
before, just kicking the can down the road.
My problem with the dynamic lower limit solution based on past blocks
is that it doesn't account for usage spikes. I would like to propose
another dynamic lower limit scheme:
Let the block size limit be a function of the number of current
transactions in the mempool. This way, bitcoin usage regulates the
block size limit.
I'm sorry i don't have the knowledge of the code base or time to make
simulations on this kind of approach, but nevertheless I would like to
leave it here for discussion or foster other ideas.
cheers
|
