To: Jeff Garzik <jgarzik@gmail.com>, Bitcoin development mailing list
	<bitcoin-dev@lists.linuxfoundation.org>
References: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <55F9E47D.50507@mattcorallo.com>
Date: Wed, 16 Sep 2015 21:51:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Precedence: list

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.