{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-18\n📝 Original message:Correction of a correction, in-line:\n\nOn Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\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\nPerhaps it is accurate to say that there wasn't consensus at all except\nthat (1) we think we can work together on resolving this impasse (yay!),\nand (2) it is conceivable that changing from block size to some other\nmetric might provide the basis for a compromise on near-term numbers.\n\nAs an example, I do not think the net-UTXO metric provides any benefit with\nrespect to scalability, and in some ways makes the situation worse (even\nthough it helpfully solves an unrelated problem of spammy dust outputs).\nBut there are other possible metrics and I maintain hope that data will\nshow the benefit of another metric or other metrics combined with net-UTXO\nin a way that will allow us to reach consensus.\n\nAs a further example, I also am quite concerned about 2-4-8MB with either\nblock size or net-UTXO as the base metric. As you say, it depends on how\nthe non-blocksize limit accounting/adjusting is done... But if a metric\nwere chosen that addressed my concerns (worst case propagation and\nvalidation time), then I could be in favor of an initial bump that allowed\na larger number of typical transactions in a block.\n\nBut where I really need to disagree is on the requirement for a 2nd hard\nfork. I will go on record as being definitively against this. While being\nconservative with respect to exponentials, I would very much like to make\nsure that there is a long-term growth curve as part of any proposal. I am\nwilling to accept a hard-fork if the adopted plan is too conservative, but\nI do not want to be kicking the can down the road to a scheduled 2nd hard\nfork that absolutely must occur. That, I feel, could be a more dangerous\noutcome than an exponential that outlasts conservative historical trends.\n\nI commend Jeff for writing a Chatham-rules summary of the outcome of some\nhallway conversations that occurred. On the whole I think his summary does\nrepresent the majority view of the opinions expressed by core developers at\nthe workshop. I will caution though that on nearly every issue there were\nthose expressed disagreement but did not fight the issue, and those who\nsaid nothing and left unpolled opinions. Nevertheless this summary is\ninformative as it feeds forwards into the design of proposals that will be\nmade prior to the Hong Kong workshop in December, in order that they have a\nhigher likelihood of success.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/ddd28331/attachment.html\u003e"}