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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yq8pG-0006ey-QX
for bitcoin-development@lists.sourceforge.net;
Wed, 06 May 2015 23:34:02 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.46 as permitted sender)
client-ip=209.85.192.46; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f46.google.com;
Received: from mail-qg0-f46.google.com ([209.85.192.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yq8pF-0003mm-ND
for bitcoin-development@lists.sourceforge.net;
Wed, 06 May 2015 23:34:02 +0000
Received: by qgdy78 with SMTP id y78so13071710qgd.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 06 May 2015 16:33:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.21.166 with SMTP id 38mr2636313qkv.88.1430955236338; Wed,
06 May 2015 16:33:56 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 6 May 2015 16:33:56 -0700 (PDT)
In-Reply-To: <554A9FD1.80103@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
<CAE-z3OXnjayLUeHBU0hdwU5pKrJ6fpj7YPtGBMQ7hKXG3Sj6hw@mail.gmail.com>
<554A9FD1.80103@bluematt.me>
Date: Thu, 7 May 2015 00:33:56 +0100
Message-ID: <CAE-z3OUCHr9KK_GE2iATu5zWxbXBF5Rvt8mvKJ=rjD3NsDDcOQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1147efce8d320a0515723afd
X-Spam-Score: 1.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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-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
1.2 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.4 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yq8pF-0003mm-ND
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:34:02 -0000
--001a1147efce8d320a0515723afd
Content-Type: text/plain; charset=UTF-8
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <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.
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.
--001a1147efce8d320a0515723afd
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">On T=
hu, May 7, 2015 at 12:12 AM, Matt Corallo <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-list@bluematt.me=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The point of the h=
ard block size limit is exactly because giving miners<br>
free rule to do anything they like with their blocks would allow them to<br=
>
do any number of crazy attacks. The incentives for miners to pick block<br>
sizes are no where near compatible with what allows the network to<br>
continue to run in a decentralized manner.<br></blockquote><div><br></div><=
div>Miners can always reduce the block size (if they coordinate).=C2=A0 Inc=
reasing the maximum block size doesn't necessarily cause an increase.=
=C2=A0 A majority of miners can soft-fork to set the limit lower than the h=
ard limit.<br><br></div><div>Setting the hard-fork limit higher means that =
a soft fork can be used to adjust the limit in the future.=C2=A0 <br><br></=
div><div>The reference client would accept blocks above the soft limit for =
wallet purposes, but not build on them.=C2=A0 Blocks above the hard limit w=
ould be rejected completely.<br></div></div></div></div>
--001a1147efce8d320a0515723afd--
|
