rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2015-09-16 📝 Original message:I only have one "correction", included inline. On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote: > > During Scaling Bitcoin, Bitcoin Core committers and notable contributors > got together and chatted about where a "greatest common denominator" > type consensus might be. The following is a without-attribution > (Chatham House) summary. This is my own personal summary of the chat; > any errors are my own; this is _not_ a consensus statement or anything > formal. > > - Background (pre-conference, was on public IRC): "net-utxo", > calculating transaction size within block by applying a delta to > transaction size based on the amount of data added, or removed, from the > UTXO set. Fee is then evaluated after the delta is applied. This > aligns user incentives with UTXO resource usage/cost. Original idea by > gmaxwell (and others??). > > - 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. > - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard > fork Y months in the future. Set high bit in version, resulting in a > negative number, to more cleanly fork away. "miner advisement" - > miners, as they've done recently, signal non-binding (Bitcoin Core does > not examine the value) engineering readiness for a hard fork via > coinbase moniker. Some fork cancellation method is useful, if > unsuccessful after Z time elapses. > > - As discussed publicly elsewhere, other forks may be signaled via > setting a bit in version, and then triggering a fork'ing change once a > threshold is reached. > > Chat participants are invited to reply to this message with their own > corrections and comments and summary in their view. > > For the wider community, take this as one of many "inputs" described at > Scaling Bitcoin. Over the next few months developers and the community > should evaluate everything discussed and work towards some concrete > proposal(s) that are implemented, tested and simulated in December in > Hong Kong.