Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5ADB6A48 for ; Fri, 13 Nov 2015 16:38:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2560B155 for ; Fri, 13 Nov 2015 16:38:12 +0000 (UTC) Received: by qkao63 with SMTP id o63so52387824qka.2 for ; Fri, 13 Nov 2015 08:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Hg6/9wXTWwsqJJP7ryVqkPWo5JY6nxopPL2H7wzSGrI=; b=Y+AsDdtv0r3sD6fDYBQQW+Us5dMBCd/bGezvwfN6NY3nnZTU7MmGRxct8bk8Psl6rB 7LfL6FS5yALje6Q7cFl5cAIwa+kqPlFLLmkfocEuBSNagcbx8jTZ+yO6nAnQJProG0lj TTKuvir/R5CRI2OKBRzzJpZogn3r1FR6rSsBn0HcBh/PDVHpS6Ilkrm5xN4Z8seclvAU ONgc+/gjWJD2KoTLAak7kX8LSI2mh9ZJjpkUTXjnsPUbsSEsa5EzQ4AQwNcOo8ps+p6i jvz25IPTBozTKIKNP/KfQNuHKSJV2uWNCZJ5WeG0aoR/QAA37eCZwayuJtgxfczE+1fX kquA== X-Received: by 10.55.197.3 with SMTP id p3mr22549406qki.11.1447432691275; Fri, 13 Nov 2015 08:38:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.132 with HTTP; Fri, 13 Nov 2015 08:37:51 -0800 (PST) From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Date: Fri, 13 Nov 2015 11:37:51 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1149a42e66605c05246eaf00 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] How to evaluate block size increase suggestions. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 16:38:13 -0000 --001a1149a42e66605c05246eaf00 Content-Type: text/plain; charset=UTF-8 By now, we have seen quite a few proposals for the block size increase. It's hard not to notice that there are potentially infinitely many functions for future block size increases. One could, for instance, double every N years for any rational number N, one could increase linearly, one could double initially then increase linearly, one could ask the miners to vote on the size, one could couple the block size increase to halvings, etc. Without judging any of these proposals on the table, one can see that there are countless alternative functions one could imagine creating. I'd like to ask a question that is one notch higher: Can we enunciate what grand goals a truly perfect function would achieve? That is, if we could look into the future and know all the improvements to come in network access technologies, see the expansion of the Bitcoin network across the globe, and precisely know the placement and provisioning of all future nodes, what metrics would we care about as we craft a function to fit what is to come? To be clear, I'd like to avoid discussing any specific block size increase function. That's very much the tangible (non-meta) block size debate, and everyone has their opinion and best good-faith attempt at what that function should look like. I've purposefully stayed out of that issue, because there are too many options and no metrics for evaluating proposals. Instead, I'm asking to see if there is some agreement on how to evaluate a good proposal. So, the meta-question: if we were looking at the best possible function, how would we know? If we have N BIPs to choose from, what criteria do we look for? To illustrate, a possible meta goal might be: "increase the block size, while ensuring that large miners never have an advantage over small miners that [they did not have in the preceding 6 months, in 2012, pick your time frame, or else specify the advantage in an absolute fashion]." Or "increase block size as much as possible, subject to the constraint that 90% of the nodes on the network are no more than 1 minute behind one of the tails of the blockchain 99% of the time." Or "do not increase the blocksize until at least date X." Or "the increase function should be monotonic." And it's quite OK (and probably likely) to have a combination of these kinds of metrics and constraints. For disclosure, I personally do not have a horse in the block size debate, besides wanting to see Bitcoin evolve and get more widely adopted. I ask because as an academic, I'd like to understand if we can use various simulation and analytic techniques to examine the proposals. A second reason is that it is very easy to have a proliferation of block size increase proposals, and good engineering would ask that we define the meta-criteria first and then pick. To do that, we need some criteria for judging proposals other than gut feeling. Of course, even with meta-criteria in hand, there will be room for lots of disagreement because we do not actually know the future and reasonable people can disagree on how things will evolve. I think this is good because it makes it easier to agree on meta-criteria than on an actual, specific function for increasing the block size. It looks like some specific meta-level criteria would help more at this point than new proposals all exploring a different variants of block size increase schedules. Best, - egs P.S. This message is an off-shoot of this blog post: http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/ --001a1149a42e66605c05246eaf00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

By now, we have seen quite a few proposals = for the block size increase. It's hard not to notice that there are pot= entially infinitely many functions for future block size increases. One cou= ld, for instance, double every N years for any rational number N, one could= increase linearly,=C2=A0one could double initially then increase linearly,= =C2=A0one could ask the miners to vote on the size, one could couple the bl= ock size increase to halvings, etc. Without judging any of these proposals = on the table, one can see that there are countless alternative functions on= e could imagine creating.

I'd like to ask a question that is one notch higher: Can= we enunciate what grand goals a truly perfect function would achieve? That= is, if we could look into the future and know all the improvements to come= in network access technologies, see the expansion of the Bitcoin network a= cross the globe, and precisely know the placement and provisioning of all f= uture nodes, what metrics would we care about as we craft a function to fit= what is to come?

To be clear, I'd like to avoid discussing any specific b= lock size increase function. That's very much the tangible (non-meta) b= lock size debate, and everyone has their opinion and best good-faith attemp= t at what that function should look like. I've purposefully stayed out = of that issue, because there are too many options and no metrics for evalua= ting proposals.=C2=A0

Instead, I'm asking to see if t= here is some agreement on how to evaluate a good proposal. So, the meta-que= stion: if we were looking at the best possible function, how would we know?= If we have N BIPs to choose from, what criteria do we look for?

To illustrate, a possible meta goal might be: "increase= the block size, while ensuring that large miners never have an advantage o= ver small miners that [they did not have in the preceding 6 months, in 2012= , pick your time frame, or else specify the advantage in an absolute fashio= n]." Or "increase block size as much as possible, subject to the = constraint that 90% of the nodes on the network are no more than 1 minute b= ehind one of the tails of the blockchain 99% of the time." Or "do= not increase the blocksize until at least date X." Or "the incre= ase function should be monotonic." And it's quite OK (and probably= likely) to have a combination of these kinds of metrics and constraints.= =C2=A0

For disclosure, I personally do not have a horse in the bloc= k size debate, besides wanting to see Bitcoin evolve and get more widely ad= opted. I ask because as an academic, I'd like to understand if we can u= se various simulation and analytic techniques to examine the proposals.=C2= =A0=C2=A0A second reason is that it is very easy to have a proliferation of= block size increase proposals, and good engineering would ask that we defi= ne the meta-criteria first and then pick. To do that, we need some criteria= for judging proposals other than gut feeling.=C2=A0

Of course, even = with meta-criteria in hand, there will be room for lots of disagreement bec= ause we do not actually know the future and reasonable people can disagree = on how things will evolve. I think this is good because it makes it easier = to agree on meta-criteria than on an actual, specific function for increasi= ng the block size.

It looks like some specific meta-level= criteria would help more at this point than new proposals all exploring a = different variants of block size increase schedules.

Best= ,

- egs


P.S. This message is an off-= shoot of this blog post:

http://hackingdistributed= .com/2015/11/13/suggestion-for-the-blocksize-debate/


=


--001a1149a42e66605c05246eaf00--