public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
@ 2015-06-22 19:32 Jean-Paul Kogelman
  2015-06-22 20:43 ` Tier Nolan
  2015-06-22 20:54 ` Peter Todd
  0 siblings, 2 replies; 62+ messages in thread
From: Jean-Paul Kogelman @ 2015-06-22 19:32 UTC (permalink / raw)
  To: Gavin Andresen; +Cc: bitcoin-dev

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



On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail•com> wrote:

The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
 
Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?

jp

[-- Attachment #2.1: Type: text/html, Size: 1206 bytes --]

^ permalink raw reply	[flat|nested] 62+ messages in thread
* Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
@ 2015-06-24 17:23 Raystonn
  2015-06-24 17:24 ` Allen Piscitello
  2015-06-24 17:28 ` Roy Badami
  0 siblings, 2 replies; 62+ messages in thread
From: Raystonn @ 2015-06-24 17:23 UTC (permalink / raw)
  To: Mark Friedenbach; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 16923 bytes --]

^ permalink raw reply	[flat|nested] 62+ messages in thread
* Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
@ 2015-06-24  4:31 Raystonn
  2015-06-24 17:05 ` Mark Friedenbach
  0 siblings, 1 reply; 62+ messages in thread
From: Raystonn @ 2015-06-24  4:31 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 15691 bytes --]

^ permalink raw reply	[flat|nested] 62+ messages in thread
* Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
@ 2015-06-23  7:59 Ross Nicoll
  0 siblings, 0 replies; 62+ messages in thread
From: Ross Nicoll @ 2015-06-23  7:59 UTC (permalink / raw)
  To: bitcoin-dev

Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth.

The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.

Ross

On 23 Jun 2015 08:35, Ross Nicoll <jrn@jrn•me.uk> wrote:

^ permalink raw reply	[flat|nested] 62+ messages in thread
* [bitcoin-dev] Draft BIP : fixed-schedule block size increase
@ 2015-06-22 18:18 Gavin Andresen
  2015-06-22 18:33 ` Tier Nolan
                   ` (7 more replies)
  0 siblings, 8 replies; 62+ messages in thread
From: Gavin Andresen @ 2015-06-22 18:18 UTC (permalink / raw)
  To: Johnathan Corgan; +Cc: bitcoin-dev

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

I promised to write a BIP after I'd implemented
increase-the-maximum-block-size code, so here it is. It also lives at:
https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

I don't expect any proposal to please everybody; there are unavoidable
tradeoffs to increasing the maximum block size. I prioritize implementation
simplicity -- it is hard to write consensus-critical code, so simpler is
better.




  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <gavinandresen@gmail•com>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

==Abstract==

This BIP proposes replacing the fixed one megabyte maximum block size with
a maximum size that grows over time at a predictable rate.

==Motivation==

Transaction volume on the Bitcoin network has been growing, and will soon
reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
maximum block size. Increasing the maximum size reduces the impact of that
limit on Bitcoin adoption and growth.

==Specification==

After deployment on the network (see the Deployment section for details),
the maximum allowed size of a block on the main network shall be calculated
based on the timestamp in the block header.

The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11
00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000
seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC
(timestamp 2083190400). The maximum size of blocks in between doublings
will increase linearly based on the block's timestamp. The maximum size of
blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.

Expressed in pseudo-code, using integer math:

    function max_block_size(block_timestamp):

        time_start = 1452470400
        time_double = 60*60*24*365*2
        size_start = 8000000
        if block_timestamp >= time_start+time_double*10
            return size_start * 2^10

        // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate

        return max_size

==Deployment==

Deployment shall be controlled by hash-power supermajority vote (similar to
the technique used in BIP34), but the earliest possible activation time is
2016-01-11 00:00:00 UTC.

Activation is achieved when 750 of 1,000 consecutive blocks in the best
chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
activation time will be the timestamp of the 750'th block plus a two week
(1,209,600 second) grace period to give any remaining miners or services
time to upgrade to support larger blocks. If a supermajority is achieved
more than two weeks before 2016-01-11 00:00:00 UTC, the activation time
will be 2016-01-11 00:00:00 UTC.

Block version numbers are used only for activation; once activation is
achieved, the maximum block size shall be as described in the specification
section, regardless of the version number of the block.


==Rationale==

The initial size of 8,000,000 bytes was chosen after testing the current
reference implementation code with larger block sizes and receiving
feedback from miners stuck behind bandwidth-constrained networks (in
particular, Chinese miners behind the Great Firewall of China).

The doubling interval was chosen based on long-term growth trends for CPU
power, storage, and Internet bandwidth. The 20-year limit was chosen
because exponential growth cannot continue forever.

Calculations are based on timestamps and not blockchain height because a
timestamp is part of every block's header. This allows implementations to
know a block's maximum size after they have downloaded it's header, but
before downloading any transactions.

The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
increase, and is designed to give miners, merchants, and
full-node-running-end-users sufficient time to upgrade to software that
supports bigger blocks. A 75% supermajority was chosen so that one large
mining pool does not have effective veto power over a blocksize increase.
The version number scheme is designed to be compatible with Pieter's
Wuille's proposed "Version bits" BIP.

TODO: summarize objections/arguments from
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.

TODO: describe other proposals and their advantages/disadvantages over this
proposal.


==Compatibility==

This is a hard-forking change to the Bitcoin protocol; anybody running code
that fully validates blocks must upgrade before the activation time or they
will risk rejecting a chain containing larger-than-one-megabyte blocks.

Simplified Payment Verification software is not affected, unless it makes
assumptions about the maximum depth of a transaction's merkle branch based
on the minimum size of a transaction and the maximum block size.

==Implementation==

https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork

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

^ permalink raw reply	[flat|nested] 62+ messages in thread

end of thread, other threads:[~2015-08-19  3:45 UTC | newest]

Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-22 19:32 [bitcoin-dev] Draft BIP : fixed-schedule block size increase Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04   ` Stephen Morse
2015-06-22 21:32     ` Ross Nicoll
2015-08-17 15:54       ` Jorge Timón
2015-06-22 21:21   ` Gavin Andresen
2015-06-22 21:39     ` Patrick Strateman
2015-06-22 21:48     ` Tier Nolan
  -- strict thread matches above, loose matches on Subject: below --
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami
2015-06-24  4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24   ` Roy Badami
2015-06-23  7:59 Ross Nicoll
2015-06-22 18:18 Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46   ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28   ` Tier Nolan
2015-06-22 19:54     ` Gavin Andresen
2015-06-22 20:12       ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23  7:35   ` Ross Nicoll
2015-08-17 15:58     ` Jorge Timón
2015-06-23 19:16   ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46   ` Gavin Andresen
2015-06-22 20:51     ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12   ` Gavin Andresen
2015-06-23 20:26     ` Pieter Wuille
2015-06-23 20:50       ` Peter Todd
2015-06-24  6:14         ` grarpamp
2015-06-23 20:46     ` Peter Todd
2015-06-23 21:24       ` Gavin Andresen
2015-06-26 19:08         ` Peter Todd
2015-06-26 22:01           ` Ivan Brightly
2015-06-26 19:25         ` Peter Todd
2015-06-26 22:16           ` Simon Liu
2015-06-27  2:14             ` Milly Bitcoin
2015-06-23 20:55     ` Roy Badami
2015-06-24  1:43 ` odinn
2015-06-24  3:05   ` William Madden
2015-06-24  3:49     ` Jeff Garzik
2015-06-24 13:06       ` Will
2015-06-24 13:44         ` Gavin Andresen
2015-06-25  0:32           ` Pindar Wong
2015-06-25 13:50       ` Gareth Williams
2015-06-25 14:07         ` Adam Back
2015-06-26 13:47           ` Tier Nolan
2015-06-26 15:13             ` Will
2015-06-26 17:39               ` Gavin Andresen
2015-06-26 19:07                 ` Will
2015-07-01 22:49             ` odinn
2015-08-17 13:15               ` Tier Nolan
2015-08-17 13:18                 ` Clément Elbaz
2015-08-19  3:45                 ` odinn
2015-08-17 16:11             ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox