rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2015-09-18 📝 Original message: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 > <bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org>> 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.