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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kanzure@gmail.com>) id 1YqlZ4-0005zx-Qy
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 16:55:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.41 as permitted sender)
client-ip=209.85.215.41; envelope-from=kanzure@gmail.com;
helo=mail-la0-f41.google.com;
Received: from mail-la0-f41.google.com ([209.85.215.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqlYz-0003cx-9T
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 16:55:54 +0000
Received: by layy10 with SMTP id y10so56831899lay.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 09:55:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.156.97 with SMTP id wd1mr3494612lbb.30.1431104142891;
Fri, 08 May 2015 09:55:42 -0700 (PDT)
Received: by 10.152.18.168 with HTTP; Fri, 8 May 2015 09:55:42 -0700 (PDT)
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
References: <16096345.A1MpJQQkRW@crushinator>
Date: Fri, 8 May 2015 11:55:42 -0500
Message-ID: <CABaSBaweJyQUdMDiegOs0U26dMto-VZt-PB8p5a+3vgyLqoGfA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>, Bryan Bishop <kanzure@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
(kanzure[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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
X-Headers-End: 1YqlYz-0003cx-9T
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: Fri, 08 May 2015 16:55:54 -0000
On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
> - Perhaps the hard block size limit should be a function of the actual block sizes over some
> trailing sampling period. For example, take the median block size among the most recent
> 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically,
> rather than having human beings guessing at what is an appropriate limit.
Block contents can be grinded much faster than hashgrinding and
mining. There is a significant run-away effect there, and it also
works in the gradual sense as a miner probabilistically mines large
blocks that get averaged into that 2016 median block size computation.
At least this proposal would be a slower way of pushing out miners and
network participants that can't handle 100 GB blocks immediately.. As
the size of the blocks are increased, low-end hardware participants
have to fall off the network because they no longer meet the minimum
performance requirements. Adjustment might become severely mismatched
with general economic trends in data storage device development or
availability or even current-market-saturation of said storage
devices. With the assistance of transaction stuffing or grinding, that
2016 block median metric can be gamed to increase faster than other
participants can keep up with or, perhaps worse, in a way that was
unintended by developers yet known to be a failure mode. These are
just some issues to keep and mind and consider.
- Bryan
http://heybryan.org/
1 512 203 0507
|
