{"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-16\n📝 Original message:I only have one \"correction\", included inline.\n\nOn 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote:\n\u003e \n\u003e During Scaling Bitcoin, Bitcoin Core committers and notable contributors\n\u003e got together and chatted about where a \"greatest common denominator\"\n\u003e type consensus might be.  The following is a without-attribution\n\u003e (Chatham House) summary.  This is my own personal summary of the chat;\n\u003e any errors are my own; this is _not_ a consensus statement or anything\n\u003e formal.\n\u003e \n\u003e - Background (pre-conference, was on public IRC): \"net-utxo\",\n\u003e calculating transaction size within block by applying a delta to\n\u003e transaction size based on the amount of data added, or removed, from the\n\u003e UTXO set.  Fee is then evaluated after the delta is applied.  This\n\u003e aligns user incentives with UTXO resource usage/cost.  Original idea by\n\u003e gmaxwell (and others??).\n\u003e \n\u003e - Many interested or at least willing to accept a \"short term bump\", a\n\u003e hard fork to modify block size limit regime to be cost-based via\n\u003e \"net-utxo\" rather than a simple static hard limit.  2-4-8 and 17%/year\n\u003e were debated and seemed \"in range\" with what might work as a short term\n\u003e bump - net after applying the new cost metric.\n\nI would be careful to point out that hard numbers were deliberately NOT\ndiscussed. Though some general things were thrown out, they were not\nextensively discussed nor agreed to. I personally think 2-4 is \"in\nrange\", though 8 maybe not so much. Of course it depends on exactly how\nthe non-blocksize limit accounting/adjusting is done.\n\nStill, the \"greatest common denominator\" agreement did not seem to be\nagreeing to an increase which continues over time, but which instead\nlimits itself to a set, smooth increase for X time and then requires a\nsecond hardfork if there is agreement on a need for more blocksize at\nthat point.\n\n\n\u003e - Hard fork method:  Leaning towards \"if (timestamp \u003e X)\" flag day hard\n\u003e fork Y months in the future.  Set high bit in version, resulting in a\n\u003e negative number, to more cleanly fork away.  \"miner advisement\" -\n\u003e miners, as they've done recently, signal non-binding (Bitcoin Core does\n\u003e not examine the value) engineering readiness for a hard fork via\n\u003e coinbase moniker.  Some fork cancellation method is useful, if\n\u003e unsuccessful after Z time elapses.\n\u003e \n\u003e - As discussed publicly elsewhere, other forks may be signaled via\n\u003e setting a bit in version, and then triggering a fork'ing change once a\n\u003e threshold is reached.\n\u003e \n\u003e Chat participants are invited to reply to this message with their own\n\u003e corrections and comments and summary in their view.\n\u003e \n\u003e For the wider community, take this as one of many \"inputs\" described at\n\u003e Scaling Bitcoin.  Over the next few months developers and the community\n\u003e should evaluate everything discussed and work towards some concrete\n\u003e proposal(s) that are implemented, tested and simulated in December in\n\u003e Hong Kong."}