public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.


  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 [bitcoin-dev] Scaling Bitcoin conference micro-report 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jgarzik@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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