{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-18\n📝 Original message:I did not intend to imply that there was agreement on a desire to\nschedule a second hardfork. My wording may have been a bit too loose.\nInstead, I believe there was much agreement that doing a short-term\nhardfork now, with many agreeing that a second would hopefully be\nentirely unnecessary/impossible, while others thought that a second\nwould be necessary and would have to happen. While this may set up a\nsimilar controversy again in several years, I think everyone agreed that\nwe cannot predict the future and I, personally, think none of us should\nbe committing to a viewpoint for what should be done at that time.\n\nPersonally, I think it is also critical that there be no messaging that\npeople should rely on or assume there will be a future increase after a\nshort-term bump (which I also do not believe people should be relying on\nnow).\n\nMatt\n\nOn 09/18/15 05:55, Mark Friedenbach wrote:\n\u003e Correction of a correction, in-line:\n\u003e \n\u003e On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e     \u003e - Many interested or at least willing to accept a \"short term bump\", a\n\u003e     \u003e hard fork to modify block size limit regime to be cost-based via\n\u003e     \u003e \"net-utxo\" rather than a simple static hard limit.  2-4-8 and 17%/year\n\u003e     \u003e were debated and seemed \"in range\" with what might work as a short term\n\u003e     \u003e bump - net after applying the new cost metric.\n\u003e \n\u003e     I would be careful to point out that hard numbers were deliberately NOT\n\u003e     discussed. Though some general things were thrown out, they were not\n\u003e     extensively discussed nor agreed to. I personally think 2-4 is \"in\n\u003e     range\", though 8 maybe not so much. Of course it depends on exactly how\n\u003e     the non-blocksize limit accounting/adjusting is done.\n\u003e \n\u003e     Still, the \"greatest common denominator\" agreement did not seem to be\n\u003e     agreeing to an increase which continues over time, but which instead\n\u003e     limits itself to a set, smooth increase for X time and then requires a\n\u003e     second hardfork if there is agreement on a need for more blocksize at\n\u003e     that point.\n\u003e \n\u003e \n\u003e Perhaps it is accurate to say that there wasn't consensus at all except\n\u003e that (1) we think we can work together on resolving this impasse (yay!),\n\u003e and (2) it is conceivable that changing from block size to some other\n\u003e metric might provide the basis for a compromise on near-term numbers.\n\u003e \n\u003e As an example, I do not think the net-UTXO metric provides any benefit\n\u003e with respect to scalability, and in some ways makes the situation worse\n\u003e (even though it helpfully solves an unrelated problem of spammy dust\n\u003e outputs). But there are other possible metrics and I maintain hope that\n\u003e data will show the benefit of another metric or other metrics combined\n\u003e with net-UTXO in a way that will allow us to reach consensus.\n\u003e \n\u003e As a further example, I also am quite concerned about 2-4-8MB with\n\u003e either block size or net-UTXO as the base metric. As you say, it depends\n\u003e on how the non-blocksize limit accounting/adjusting is done... But if a\n\u003e metric were chosen that addressed my concerns (worst case propagation\n\u003e and validation time), then I could be in favor of an initial bump that\n\u003e allowed a larger number of typical transactions in a block.\n\u003e \n\u003e But where I really need to disagree is on the requirement for a 2nd hard\n\u003e fork. I will go on record as being definitively against this. While\n\u003e being conservative with respect to exponentials, I would very much like\n\u003e to make sure that there is a long-term growth curve as part of any\n\u003e proposal. I am willing to accept a hard-fork if the adopted plan is too\n\u003e conservative, but I do not want to be kicking the can down the road to a\n\u003e scheduled 2nd hard fork that absolutely must occur. That, I feel, could\n\u003e be a more dangerous outcome than an exponential that outlasts\n\u003e conservative historical trends.\n\u003e \n\u003e I commend Jeff for writing a Chatham-rules summary of the outcome of\n\u003e some hallway conversations that occurred. On the whole I think his\n\u003e summary does represent the majority view of the opinions expressed by\n\u003e core developers at the workshop. I will caution though that on nearly\n\u003e every issue there were those expressed disagreement but did not fight\n\u003e the issue, and those who said nothing and left unpolled opinions.\n\u003e Nevertheless this summary is informative as it feeds forwards into the\n\u003e design of proposals that will be made prior to the Hong Kong workshop in\n\u003e December, in order that they have a higher likelihood of success."}