public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ross Nicoll <jrn@jrn.me.uk>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Date: Fri, 17 Jul 2015 20:13:14 +0100	[thread overview]
Message-ID: <55A953CA.7020701@jrn.me.uk> (raw)
In-Reply-To: <CAEieSeQs4OmyKr4AMcXhZfRccwPApzNJyd06yhRTOjYywsVLsQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

I'll leave others to comment on whether we can get consensus on that, 
but your years listed are inconsistent with everything else you've 
written. Should be:

block 400,000 = 2MB (2016)
block 500,000 = 4MB (2018)
block 600,000 = 8MB (2020)

On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote:
> I would prefer a dynamic solution that did not necessitate a second 
> hard fork down the road.
>
> I propose doubling the block size every 100k blocks (~2 years)
>
> block 400,000 = 2MB (2016)
> block 500,000 = 4MB (2017)
> block 600,000 = 8MB (2018)
>
> Chris
>
>
> On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     I'd back this if we can't find a permanent solution - 2MB gives us
>     a lot more wiggle room in the interim at least; one of my concerns
>     with block size is 3 transactions per second is absolutely tiny,
>     and we need space for the network to search for an equilibrium
>     between volume and pricing without risk of an adoption spike
>     rendering it essentially unusable.
>
>     I'd favour switching over by block height rather than time, and
>     I'd suggest that given virtually every wallet/node out there will
>     require testing (even if many do not currently enforce a limit and
>     therefore do not need changing), 6 months should be considered a
>     minimum target. I'd open with a suggestion of block 390k as a target.
>
>     Ross
>
>
>     On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>>     Opening a mailing list thread on this BIP:
>>
>>     BIP PR: https://github.com/bitcoin/bips/pull/173
>>     Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>>
>>     The general intent of this BIP is as a minimum viable alternative
>>     plan to my preferred proposal (BIP 100).
>>
>>     If agreement is not reached on a more comprehensive solution,
>>     then this solution is at least available and a known quantity.  A
>>     good backup plan.
>>
>>     Benefits:  conservative increase.  proves network can upgrade.
>>      permits some added growth, while the community & market gathers
>>     data on how an increased block size impacts privacy, security,
>>     centralization, transaction throughput and other metrics.  2MB
>>     seems to be a Least Common Denominator on an increase.
>>
>>     Costs:  requires a hard fork.  requires another hard fork down
>>     the road.
>>
>>
>>
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 7305 bytes --]

  reply	other threads:[~2015-07-17 19:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14   ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06   ` Chris Wardell
2015-07-17 19:13     ` Ross Nicoll [this message]
2015-07-19 22:51   ` Ross Nicoll
2015-07-21  9:26     ` Jorge Timón
2015-07-21 13:04       ` Peter Todd
2015-07-21 13:58         ` Peter Todd
2015-07-22 15:51           ` Tom Harding
2015-07-22 17:02           ` Sriram Karra
2015-07-22 17:40             ` Sriram Karra
2015-07-22 17:43           ` Jeff Garzik
2015-07-22 22:30             ` Peter Todd
2015-07-23  5:39               ` jl2012
2015-07-22 17:00         ` jl2012
2015-07-21 22:05       ` Ross Nicoll
2015-07-23 11:24         ` Jorge Timón
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13   ` Angel Leon
2015-07-17 22:25   ` Tier Nolan
2015-07-18  9:22     ` Jorge Timón
2015-07-18  9:24       ` Jorge Timón
2015-07-24  8:52   ` Thomas Zander
2015-07-24  9:43     ` Slurms MacKenzie
2015-07-18  4:32 ` Venzen Khaosan
2015-07-17 22:40 Raystonn

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=55A953CA.7020701@jrn.me.uk \
    --to=jrn@jrn.me.uk \
    --cc=bitcoin-dev@lists.linuxfoundation.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