📅 Original date posted:2015-06-22
📝 Original message:Thank you!
A few questions/comments:
* In the specification, you refer to "t_start". I guess you mean "time_start"?
* Miners can, especially when close to a block doubling or shortly
after activation, to some extent manipulate max block size by
manipulating the time stamp in the block header within valid limits.
According to the pseudo code in the specification, the first and a
handful of subsequent blocks after activation could actually have
negative max block sizes due to this (depending on how you define the
% operator of the pseudo code). I haven't checked the reference
implementation, but I do think that the specification section should
explicitly handle this.
Regards,
Kalle
2015-06-22 20:18 GMT+02:00 Gavin Andresen <gavinandresen at gmail.com>:
> 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 at 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 15:39:43
in reply to nevent1q…d4h5
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 15:39:43Event JSON
{
"id": "7c7a26e4fbbea6734f404420d4aaf65f2cf0ebb1fb5e6943d196ecdb25ef31b7",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686152383,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"632041ffceb535de7a840a72b6ef3ee3d2aa275403a1b2da428fab57a639c8bb",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-06-22\n📝 Original message:Thank you!\n\nA few questions/comments:\n\n* In the specification, you refer to \"t_start\". I guess you mean \"time_start\"?\n\n* Miners can, especially when close to a block doubling or shortly\nafter activation, to some extent manipulate max block size by\nmanipulating the time stamp in the block header within valid limits.\nAccording to the pseudo code in the specification, the first and a\nhandful of subsequent blocks after activation could actually have\nnegative max block sizes due to this (depending on how you define the\n% operator of the pseudo code). I haven't checked the reference\nimplementation, but I do think that the specification section should\nexplicitly handle this.\n\nRegards,\nKalle\n\n2015-06-22 20:18 GMT+02:00 Gavin Andresen \u003cgavinandresen at gmail.com\u003e:\n\u003e I promised to write a BIP after I'd implemented\n\u003e increase-the-maximum-block-size code, so here it is. It also lives at:\n\u003e https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki\n\u003e\n\u003e I don't expect any proposal to please everybody; there are unavoidable\n\u003e tradeoffs to increasing the maximum block size. I prioritize implementation\n\u003e simplicity -- it is hard to write consensus-critical code, so simpler is\n\u003e better.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e BIP: ??\n\u003e Title: Increase Maximum Block Size\n\u003e Author: Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2015-06-22\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e This BIP proposes replacing the fixed one megabyte maximum block size with a\n\u003e maximum size that grows over time at a predictable rate.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e Transaction volume on the Bitcoin network has been growing, and will soon\n\u003e reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte\n\u003e maximum block size. Increasing the maximum size reduces the impact of that\n\u003e limit on Bitcoin adoption and growth.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e After deployment on the network (see the Deployment section for details),\n\u003e the maximum allowed size of a block on the main network shall be calculated\n\u003e based on the timestamp in the block header.\n\u003e\n\u003e The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11\n\u003e 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000\n\u003e seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC\n\u003e (timestamp 2083190400). The maximum size of blocks in between doublings will\n\u003e increase linearly based on the block's timestamp. The maximum size of blocks\n\u003e after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.\n\u003e\n\u003e Expressed in pseudo-code, using integer math:\n\u003e\n\u003e function max_block_size(block_timestamp):\n\u003e\n\u003e time_start = 1452470400\n\u003e time_double = 60*60*24*365*2\n\u003e size_start = 8000000\n\u003e if block_timestamp \u003e= time_start+time_double*10\n\u003e return size_start * 2^10\n\u003e\n\u003e // Piecewise-linear-between-doublings growth:\n\u003e time_delta = block_timestamp - t_start\n\u003e doublings = time_delta / time_double\n\u003e remainder = time_delta % time_double\n\u003e interpolate = (size_start * 2^doublings * remainder) / time_double\n\u003e max_size = size_start * 2^doublings + interpolate\n\u003e\n\u003e return max_size\n\u003e\n\u003e ==Deployment==\n\u003e\n\u003e Deployment shall be controlled by hash-power supermajority vote (similar to\n\u003e the technique used in BIP34), but the earliest possible activation time is\n\u003e 2016-01-11 00:00:00 UTC.\n\u003e\n\u003e Activation is achieved when 750 of 1,000 consecutive blocks in the best\n\u003e chain have a version number with bits 3 and 14 set (0x20000004 in hex). The\n\u003e activation time will be the timestamp of the 750'th block plus a two week\n\u003e (1,209,600 second) grace period to give any remaining miners or services\n\u003e time to upgrade to support larger blocks. If a supermajority is achieved\n\u003e more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will\n\u003e be 2016-01-11 00:00:00 UTC.\n\u003e\n\u003e Block version numbers are used only for activation; once activation is\n\u003e achieved, the maximum block size shall be as described in the specification\n\u003e section, regardless of the version number of the block.\n\u003e\n\u003e\n\u003e ==Rationale==\n\u003e\n\u003e The initial size of 8,000,000 bytes was chosen after testing the current\n\u003e reference implementation code with larger block sizes and receiving feedback\n\u003e from miners stuck behind bandwidth-constrained networks (in particular,\n\u003e Chinese miners behind the Great Firewall of China).\n\u003e\n\u003e The doubling interval was chosen based on long-term growth trends for CPU\n\u003e power, storage, and Internet bandwidth. The 20-year limit was chosen because\n\u003e exponential growth cannot continue forever.\n\u003e\n\u003e Calculations are based on timestamps and not blockchain height because a\n\u003e timestamp is part of every block's header. This allows implementations to\n\u003e know a block's maximum size after they have downloaded it's header, but\n\u003e before downloading any transactions.\n\u003e\n\u003e The deployment plan is taken from Jeff Garzik's proposed BIP100 block size\n\u003e increase, and is designed to give miners, merchants, and\n\u003e full-node-running-end-users sufficient time to upgrade to software that\n\u003e supports bigger blocks. A 75% supermajority was chosen so that one large\n\u003e mining pool does not have effective veto power over a blocksize increase.\n\u003e The version number scheme is designed to be compatible with Pieter's\n\u003e Wuille's proposed \"Version bits\" BIP.\n\u003e\n\u003e TODO: summarize objections/arguments from\n\u003e http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.\n\u003e\n\u003e TODO: describe other proposals and their advantages/disadvantages over this\n\u003e proposal.\n\u003e\n\u003e\n\u003e ==Compatibility==\n\u003e\n\u003e This is a hard-forking change to the Bitcoin protocol; anybody running code\n\u003e that fully validates blocks must upgrade before the activation time or they\n\u003e will risk rejecting a chain containing larger-than-one-megabyte blocks.\n\u003e\n\u003e Simplified Payment Verification software is not affected, unless it makes\n\u003e assumptions about the maximum depth of a transaction's merkle branch based\n\u003e on the minimum size of a transaction and the maximum block size.\n\u003e\n\u003e ==Implementation==\n\u003e\n\u003e https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "af8ab35101dac9cb17131eef552fa8cf090478bcec4377f741cb5c9c6c5cb21ece0525bc3d73997516ffa9ea6d5c93a03d4c9820d7f480b4e4cb27c40e815b67"
}