Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-16 📝 Original message:I only have one ...

📅 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.