From: Matt Corallo <lf-lists@mattcorallo•com>
To: Jeff Garzik <jgarzik@gmail•com>,
Bitcoin development mailing list
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Date: Wed, 16 Sep 2015 21:51:57 +0000 [thread overview]
Message-ID: <55F9E47D.50507@mattcorallo.com> (raw)
In-Reply-To: <CADm_WcaLKqhR=WcJ5B52Q9SAAa+AdZY6Kz5OCQVUc_RQm6e9gg@mail.gmail.com>
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.
next prev parent reply other threads:[~2015-09-16 21:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 21:32 Jeff Garzik
2015-09-16 21:51 ` Matt Corallo [this message]
2015-09-18 5:55 ` Mark Friedenbach
2015-09-18 17:10 ` Dave Scotese
2015-09-18 17:28 ` Eric Lombrozo
2015-09-18 20:06 ` Matt Corallo
2015-09-18 22:33 ` Mike Hearn
2015-09-19 16:03 ` cipher anthem
2015-09-19 20:43 ` Mike Hearn
2015-09-19 1:47 ` Peter Todd
2015-09-19 6:06 ` NxtChg
2015-09-19 6:56 ` Eric Voskuil
2015-09-19 7:27 ` NxtChg
2015-09-19 7:39 ` Eric Voskuil
2015-09-19 7:57 ` NxtChg
2015-09-19 8:52 ` Eric Voskuil
2015-09-19 13:32 ` NxtChg
2015-09-19 20:57 ` Mike Hearn
2015-09-19 21:53 ` phm
2015-09-20 1:26 ` Dave Scotese
2015-09-20 2:18 ` Milly Bitcoin
2015-09-20 9:18 ` NxtChg
2015-09-20 9:25 ` Mike Hearn
2015-09-20 15:43 ` Mark Friedenbach
2015-09-20 16:21 ` NxtChg
2015-09-20 16:34 ` Milly Bitcoin
2015-09-20 20:23 ` Steven Pine
2015-09-20 20:54 ` Milly Bitcoin
2015-09-20 21:33 ` s7r
2015-09-20 21:45 ` Eric Lombrozo
2015-09-20 22:02 ` Milly Bitcoin
2015-09-20 22:21 ` Eric Lombrozo
2015-09-20 22:51 ` Milly Bitcoin
2015-09-20 23:11 ` Eric Lombrozo
2015-09-21 0:11 ` Dave Scotese
2015-09-21 5:04 ` Corey Haddad
2015-09-21 11:45 ` Milly Bitcoin
2015-09-21 8:48 ` NxtChg
2015-09-20 21:10 ` NxtChg
2015-09-20 21:13 ` Steven Pine
2015-09-20 21:34 ` Milly Bitcoin
2015-09-20 21:24 ` Milly Bitcoin
2015-09-20 21:16 ` Eric Lombrozo
2015-09-21 10:30 ` Mike Hearn
2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc
2015-09-20 11:41 ` Isidor Zeuner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F9E47D.50507@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox