From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzwaG-0006Rp-Ia for bitcoin-development@lists.sourceforge.net; Wed, 03 Jun 2015 00:31:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.51 as permitted sender) client-ip=209.85.213.51; envelope-from=stephencalebmorse@gmail.com; helo=mail-yh0-f51.google.com; Received: from mail-yh0-f51.google.com ([209.85.213.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzwaF-0002w2-P9 for bitcoin-development@lists.sourceforge.net; Wed, 03 Jun 2015 00:31:04 +0000 Received: by yhom41 with SMTP id m41so46000702yho.1 for ; Tue, 02 Jun 2015 17:30:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.128.139 with SMTP id u133mr36146808ykb.49.1433291458204; Tue, 02 Jun 2015 17:30:58 -0700 (PDT) Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 17:30:58 -0700 (PDT) In-Reply-To: <2342620.MypLiFWdOh@crushinator> References: <2342620.MypLiFWdOh@crushinator> Date: Tue, 2 Jun 2015 20:30:58 -0400 Message-ID: From: Stephen Morse To: Matt Whitlock Content-Type: multipart/alternative; boundary=001a11395ece39d8890517922c97 X-Spam-Score: -0.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 (stephencalebmorse[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 X-Headers-End: 1YzwaF-0002w2-P9 Cc: bitcoin-development Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure 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: Wed, 03 Jun 2015 00:31:04 -0000 --001a11395ece39d8890517922c97 Content-Type: text/plain; charset=UTF-8 > > Why do it as an OP_RETURN output? It could be a simple token in the > coinbase input script, similar to how support for P2SH was signaled among > miners. And why should there be an explicit token for voting for the status > quo? Simply omitting any indication should be an implicit vote for the > status quo. A miner would only need to insert an indicator into their block > if they wished for a larger block. > I don't really care the exact location it's put in. I just thought there wasn't an explicit need to put it in the header (via a bit of nVersion), and the scriptSig is already used for many things (block height, merged mining hash, "\"P2SH\"", miner identifier). And voting to keep the block size the same by not voting is fine by me. > That said, proposals of this type have been discussed before, and the > objection is always that miners would want larger blocks than the rest of > the network could bear. Unless you want Bitcoin to become centralized in > the hands of a few large mining pools, you shouldn't hand control over the > block size limits to the miners. > Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the other day. I now think that this could be useful to dynamically increase a lower limit, but that there should still be a hard upper limit like 20 MB. I think that just changing the upper limit might be simpler and better, though. - Stephen --001a11395ece39d8890517922c97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why do it as an OP_RETURN output? It could be a simple token i= n the coinbase input script, similar to how support for P2SH was signaled a= mong miners. And why should there be an explicit token for voting for the s= tatus quo? Simply omitting any indication should be an implicit vote for th= e status quo. A miner would only need to insert an indicator into their blo= ck if they wished for a larger block.

I= don't really care the exact location it's put in. I just thought t= here wasn't an explicit need to put it in the header (via a bit of nVer= sion), and the scriptSig is already used for many things (block height, mer= ged mining hash, "\"P2SH\"", miner identifier). And vot= ing to keep the block size the same by not voting is fine by me.=C2=A0
=C2=A0
That said, proposals of this type have b= een discussed before, and the objection is always that miners would want la= rger blocks than the rest of the network could bear. Unless you want Bitcoi= n to become centralized in the hands of a few large mining pools, you shoul= dn't hand control over the block size limits to the miners.

Yeah, that was the conclusion we came to chatting = on #bitcoin-wizards the other day. I now think that this could be useful to= dynamically increase a lower limit, but that there should still be a hard = upper limit like 20 MB. I think that just changing the upper limit might be= simpler and better, though.

- Stephen
=
--001a11395ece39d8890517922c97--