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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Yq8wl-00054L-DM
for bitcoin-development@lists.sourceforge.net;
Wed, 06 May 2015 23:41:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me
designates 192.241.179.72 as permitted sender)
client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
helo=mail.bluematt.me;
Received: from mail.bluematt.me ([192.241.179.72])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Yq8wi-00085l-44
for bitcoin-development@lists.sourceforge.net;
Wed, 06 May 2015 23:41:47 +0000
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 555C154357;
Wed, 6 May 2015 23:41:38 +0000 (UTC)
Message-ID: <554AA6B1.8030701@bluematt.me>
Date: Wed, 06 May 2015 23:41:37 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tier Nolan <tier.nolan@gmail.com>
References: <554A91BE.6060105@bluematt.me> <CAE-z3OXnjayLUeHBU0hdwU5pKrJ6fpj7YPtGBMQ7hKXG3Sj6hw@mail.gmail.com> <554A9FD1.80103@bluematt.me>
<CAE-z3OUCHr9KK_GE2iATu5zWxbXBF5Rvt8mvKJ=rjD3NsDDcOQ@mail.gmail.com>
In-Reply-To: <CAE-z3OUCHr9KK_GE2iATu5zWxbXBF5Rvt8mvKJ=rjD3NsDDcOQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Yq8wi-00085l-44
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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: Wed, 06 May 2015 23:41:47 -0000
On 05/06/15 23:33, Tier Nolan wrote:
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list@bluematt.me
> <mailto:bitcoin-list@bluematt.me>> wrote:
>
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
>
>
> Miners can always reduce the block size (if they coordinate).
> Increasing the maximum block size doesn't necessarily cause an
> increase. A majority of miners can soft-fork to set the limit lower
> than the hard limit.
Sure, of course.
> Setting the hard-fork limit higher means that a soft fork can be used to
> adjust the limit in the future.
>
> The reference client would accept blocks above the soft limit for wallet
> purposes, but not build on them. Blocks above the hard limit would be
> rejected completely.
Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee left on the table by transactions not
included in a block) there becomes incentive for miners to change that
behavior pretty quick. Not just that, the vast majority of the hashpower
is behind very large miners, who have little to no decentralization
pressure. This results in very incompatible incentives, mainly that the
incentive would be for the large miners to interconnect in a private
network and generate only maximum-size blocks, creating a strong
centralization pressure in the network.
|
