public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Mark Friedenbach <mark@friedenbach.org>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
Date: Fri, 18 Sep 2015 20:06:23 +0000	[thread overview]
Message-ID: <55FC6EBF.9090504@mattcorallo.com> (raw)
In-Reply-To: <CAOG=w-t2ZYQbx8+mG5FX8vzgAC_tb8A6KMABmudHQbrquEqX-Q@mail.gmail.com>

I did not intend to imply that there was agreement on a desire to
schedule a second hardfork. My wording may have been a bit too loose.
Instead, I believe there was much agreement that doing a short-term
hardfork now, with many agreeing that a second would hopefully be
entirely unnecessary/impossible, while others thought that a second
would be necessary and would have to happen. While this may set up a
similar controversy again in several years, I think everyone agreed that
we cannot predict the future and I, personally, think none of us should
be committing to a viewpoint for what should be done at that time.

Personally, I think it is also critical that there be no messaging that
people should rely on or assume there will be a future increase after a
short-term bump (which I also do not believe people should be relying on
now).

Matt

On 09/18/15 05:55, Mark Friedenbach wrote:
> Correction of a correction, in-line:
> 
> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     > - 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.
> 
> 
> Perhaps it is accurate to say that there wasn't consensus at all except
> that (1) we think we can work together on resolving this impasse (yay!),
> and (2) it is conceivable that changing from block size to some other
> metric might provide the basis for a compromise on near-term numbers.
> 
> As an example, I do not think the net-UTXO metric provides any benefit
> with respect to scalability, and in some ways makes the situation worse
> (even though it helpfully solves an unrelated problem of spammy dust
> outputs). But there are other possible metrics and I maintain hope that
> data will show the benefit of another metric or other metrics combined
> with net-UTXO in a way that will allow us to reach consensus.
> 
> As a further example, I also am quite concerned about 2-4-8MB with
> either block size or net-UTXO as the base metric. As you say, it depends
> on how the non-blocksize limit accounting/adjusting is done... But if a
> metric were chosen that addressed my concerns (worst case propagation
> and validation time), then I could be in favor of an initial bump that
> allowed a larger number of typical transactions in a block.
> 
> But where I really need to disagree is on the requirement for a 2nd hard
> fork. I will go on record as being definitively against this. While
> being conservative with respect to exponentials, I would very much like
> to make sure that there is a long-term growth curve as part of any
> proposal. I am willing to accept a hard-fork if the adopted plan is too
> conservative, but I do not want to be kicking the can down the road to a
> scheduled 2nd hard fork that absolutely must occur. That, I feel, could
> be a more dangerous outcome than an exponential that outlasts
> conservative historical trends.
> 
> I commend Jeff for writing a Chatham-rules summary of the outcome of
> some hallway conversations that occurred. On the whole I think his
> summary does represent the majority view of the opinions expressed by
> core developers at the workshop. I will caution though that on nearly
> every issue there were those expressed disagreement but did not fight
> the issue, and those who said nothing and left unpolled opinions.
> Nevertheless this summary is informative as it feeds forwards into the
> design of proposals that will be made prior to the Hong Kong workshop in
> December, in order that they have a higher likelihood of success.


  parent reply	other threads:[~2015-09-18 20:06 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
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 [this message]
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=55FC6EBF.9090504@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mark@friedenbach.org \
    /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