From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 08D5015FF for ; Fri, 18 Sep 2015 20:06:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 397B32E3 for ; Fri, 18 Sep 2015 20:06:27 +0000 (UTC) Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 4406D584E7; Fri, 18 Sep 2015 20:06:23 +0000 (UTC) To: Mark Friedenbach References: <55F9E47D.50507@mattcorallo.com> From: Matt Corallo X-Enigmail-Draft-Status: N1110 Message-ID: <55FC6EBF.9090504@mattcorallo.com> Date: Fri, 18 Sep 2015 20:06:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 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, 18 Sep 2015 20:06:28 -0000 I did not intend to imply that there was agreement on a desire to schedule a second hardfork. My wording may have been a bit too loose. Instead, I believe there was much agreement that doing a short-term hardfork now, with many agreeing that a second would hopefully be entirely unnecessary/impossible, while others thought that a second would be necessary and would have to happen. While this may set up a similar controversy again in several years, I think everyone agreed that we cannot predict the future and I, personally, think none of us should be committing to a viewpoint for what should be done at that time. Personally, I think it is also critical that there be no messaging that people should rely on or assume there will be a future increase after a short-term bump (which I also do not believe people should be relying on now). Matt On 09/18/15 05:55, Mark Friedenbach wrote: > Correction of a correction, in-line: > > On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev > > wrote: > > > - Many interested or at least willing to accept a "short term bump", a > > hard fork to modify block size limit regime to be cost-based via > > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > > were debated and seemed "in range" with what might work as a short term > > bump - net after applying the new cost metric. > > I would be careful to point out that hard numbers were deliberately NOT > discussed. Though some general things were thrown out, they were not > extensively discussed nor agreed to. I personally think 2-4 is "in > range", though 8 maybe not so much. Of course it depends on exactly how > the non-blocksize limit accounting/adjusting is done. > > Still, the "greatest common denominator" agreement did not seem to be > agreeing to an increase which continues over time, but which instead > limits itself to a set, smooth increase for X time and then requires a > second hardfork if there is agreement on a need for more blocksize at > that point. > > > Perhaps it is accurate to say that there wasn't consensus at all except > that (1) we think we can work together on resolving this impasse (yay!), > and (2) it is conceivable that changing from block size to some other > metric might provide the basis for a compromise on near-term numbers. > > As an example, I do not think the net-UTXO metric provides any benefit > with respect to scalability, and in some ways makes the situation worse > (even though it helpfully solves an unrelated problem of spammy dust > outputs). But there are other possible metrics and I maintain hope that > data will show the benefit of another metric or other metrics combined > with net-UTXO in a way that will allow us to reach consensus. > > As a further example, I also am quite concerned about 2-4-8MB with > either block size or net-UTXO as the base metric. As you say, it depends > on how the non-blocksize limit accounting/adjusting is done... But if a > metric were chosen that addressed my concerns (worst case propagation > and validation time), then I could be in favor of an initial bump that > allowed a larger number of typical transactions in a block. > > But where I really need to disagree is on the requirement for a 2nd hard > fork. I will go on record as being definitively against this. While > being conservative with respect to exponentials, I would very much like > to make sure that there is a long-term growth curve as part of any > proposal. I am willing to accept a hard-fork if the adopted plan is too > conservative, but I do not want to be kicking the can down the road to a > scheduled 2nd hard fork that absolutely must occur. That, I feel, could > be a more dangerous outcome than an exponential that outlasts > conservative historical trends. > > I commend Jeff for writing a Chatham-rules summary of the outcome of > some hallway conversations that occurred. On the whole I think his > summary does represent the majority view of the opinions expressed by > core developers at the workshop. I will caution though that on nearly > every issue there were those expressed disagreement but did not fight > the issue, and those who said nothing and left unpolled opinions. > Nevertheless this summary is informative as it feeds forwards into the > design of proposals that will be made prior to the Hong Kong workshop in > December, in order that they have a higher likelihood of success.