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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YqoFa-0005ju-QT
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 19:47:58 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.179 as permitted sender)
client-ip=209.85.220.179; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f179.google.com;
Received: from mail-qk0-f179.google.com ([209.85.220.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqoFa-00085M-2T
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 19:47:58 +0000
Received: by qkx62 with SMTP id 62so55222778qkx.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 12:47:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.21.166 with SMTP id 38mr11392716qkv.88.1431114472586;
Fri, 08 May 2015 12:47:52 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 8 May 2015 12:47:52 -0700 (PDT)
In-Reply-To: <20150508163701.GA27417@savin.petertodd.org>
References: <554BE0E1.5030001@bluematt.me>
<CANEZrP3uKLvzKi-wXBJWL=pwqB+eAe3FbPjyESD52y5TGkg+Rg@mail.gmail.com>
<20150508163701.GA27417@savin.petertodd.org>
Date: Fri, 8 May 2015 20:47:52 +0100
Message-ID: <CAE-z3OV8zyUyYiGNRZZbTkUZz70KK7P-ENyhsKe+yhZmNnqRuQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1147efcec5829d0515974d2a
X-Spam-Score: 1.7 (+)
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.6 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqoFa-00085M-2T
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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 19:47:58 -0000
--001a1147efcec5829d0515974d2a
Content-Type: text/plain; charset=UTF-8
On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete@petertodd.org> wrote:
> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>
I wonder if having a "miner" flag would be good for the network.
Clients for general users and merchants would have a less strict rule than
the rule for miners. Miners who don't set their miners flag might get
orphaned off the chain.
For example, the limits could be setup as follows.
Clients: 20MB
Miners: 4MB
When in "miner mode", the client would reject 4MB blocks and wouldn't build
on them. The reference client might even track the miner and the non-miner
chain tip.
Miners would refuse to build on 5MB blocks, but merchants and general users
would accept them.
This allows the miners to soft fork the limit at some point in the future.
If 75% of miners decided to up the limit to 8MB, then all merchants and the
general users would accept the new blocks. It could follow the standard
soft fork rules.
This is a more general version of the system where miners are allowed to
vote on the block size (subject to a higher limit).
A similar system is where clients track all header trees. Your wallet
could warn you that there is an invalid tree that has > 75% of the hashing
power and you might want to upgrade.
--001a1147efcec5829d0515974d2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, May 8, 2015 at 5:37 PM, Peter Todd <span dir=3D"lt=
r"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@peterto=
dd.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>The soft-limit is there miners themselves produce smaller blocks; th=
e<br>
soft-limit does not prevent other miners from producing larger blocks.<br><=
/blockquote><div><br></div><div>I wonder if having a "miner" flag=
would be good for the network.<br><br></div><div>Clients for general users=
and merchants would have a less strict rule than the rule for miners.=C2=
=A0 Miners who don't set their miners flag might get orphaned off the c=
hain.<br><br></div><div>For example, the limits could be setup as follows.<=
br><br></div><div>Clients: 20MB<br></div><div>Miners: 4MB<br><br></div><div=
>When in "miner mode", the client would reject 4MB blocks and wou=
ldn't build on them.=C2=A0 The reference client might even track the mi=
ner and the non-miner chain tip.<br><br></div><div>Miners would refuse to b=
uild on 5MB blocks, but merchants and general users would accept them.<br><=
/div><div><br></div><div>This allows the miners to soft fork the limit at s=
ome point in the future.=C2=A0 If 75% of miners decided to up the limit to =
8MB, then all merchants and the general users would accept the new blocks.=
=C2=A0 It could follow the standard soft fork rules.<br><br></div><div>This=
is a more general version of the system where miners are allowed to vote o=
n the block size (subject to a higher limit).<br><br></div><div>A similar s=
ystem is where clients track all header trees.=C2=A0 Your wallet could warn=
you that there is an invalid tree that has > 75% of the hashing power a=
nd you might want to upgrade.<br></div></div></div></div>
--001a1147efcec5829d0515974d2a--
|
