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.
next prev 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mark@friedenbach$(echo .)org \
/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