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 ) 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 ; 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> <20150508163701.GA27417@savin.petertodd.org> Date: Fri, 8 May 2015 20:47:52 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On Fri, May 8, 2015 at 5:37 PM, Peter Todd <pete@peterto= dd.org> wrote:
The soft-limit is there miners themselves produce smaller blocks; th= e
soft-limit does not prevent other miners from producing larger blocks.
<= /blockquote>

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.=C2= =A0 Miners who don't set their miners flag might get orphaned off the c= hain.

For example, the limits could be setup as follows.<= br>
Clients: 20MB
Miners: 4MB

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.

Miners would refuse to b= uild on 5MB blocks, but merchants and general users would accept them.
<= /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.

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).

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.
--001a1147efcec5829d0515974d2a--