📅 Original date posted:2015-06-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1) Hard fork not (necessarily) needed
2) See Garzik's BIP 100, better (this is not meant to say "superior to
your stuff," but rather simply to say, "Better you should work with
Garzik to implement BIP-100, that would be good")
3) See points 1 and 2 above
4) If still reading... changes should be (as you seem to have been
trying to lean towards)... lean towards gradual change; hence, changes
that would flow from this BIP would be better off oriented in a
process that dies not require the "way you have done it."
You did address that, to be fair - in your TODO, this link:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
contained the following link:
http://gavinandresen.ninja/bigger-blocks-another-way
However, in reading that, I didn't see any meaningful statements that
would refute the approach in Garzik's BIP-100.
Maybe a better way to say this is,
Work with Jeff Garzik (which I am sure you are already having such
discussions in private) as well as the list discussions,
Move forward on BIP-100 with Garzik and other developers (not such a
bad plan really) and don't get caught up in XT. (If you feel you can
develop XT further, that is your thing but it would perhaps make you
lose focus, work together with other developers.)
Relax into the process. Things will be ok.
Respectfully,
- -O
On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> 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 <mailto: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
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
=ft62
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 15:39:48
in reply to nevent1q…mvm5
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 15:39:48Event JSON
{
"id": "5c90f3c05a130b169c3abc789f472e57332c0f80c3cd191c4827a8821fc5f2c8",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686152388,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"764be3f4a1731c05a5fa46b789d0a7ae4aa8fe1e36b522a245fb091bc3922434",
"",
"reply"
],
[
"p",
"58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950"
]
],
"content": "📅 Original date posted:2015-06-23\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n1) Hard fork not (necessarily) needed\n2) See Garzik's BIP 100, better (this is not meant to say \"superior to\nyour stuff,\" but rather simply to say, \"Better you should work with\nGarzik to implement BIP-100, that would be good\")\n3) See points 1 and 2 above\n4) If still reading... changes should be (as you seem to have been\ntrying to lean towards)... lean towards gradual change; hence, changes\nthat would flow from this BIP would be better off oriented in a\nprocess that dies not require the \"way you have done it.\"\n\nYou did address that, to be fair - in your TODO, this link:\nhttp://gavinandresen.ninja/time-to-roll-out-bigger-blocks\n\ncontained the following link:\n\nhttp://gavinandresen.ninja/bigger-blocks-another-way\n\nHowever, in reading that, I didn't see any meaningful statements that\nwould refute the approach in Garzik's BIP-100.\n\nMaybe a better way to say this is,\n\nWork with Jeff Garzik (which I am sure you are already having such\ndiscussions in private) as well as the list discussions,\nMove forward on BIP-100 with Garzik and other developers (not such a\nbad plan really) and don't get caught up in XT. (If you feel you can\ndevelop XT further, that is your thing but it would perhaps make you\nlose focus, work together with other developers.)\n\nRelax into the process. Things will be ok.\n\nRespectfully,\n\n- -O\n\nOn 06/22/2015 11:18 AM, Gavin Andresen wrote:\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\n\u003e 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\n\u003e unavoidable tradeoffs to increasing the maximum block size. I\n\u003e prioritize implementation simplicity -- it is hard to write\n\u003e consensus-critical code, so simpler is better.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen\n\u003e \u003cgavinandresen at gmail.com \u003cmailto:gavinandresen at gmail.com\u003e\u003e Status:\n\u003e Draft Type: Standards Track Created: 2015-06-22\n\u003e \n\u003e ==Abstract==\n\u003e \n\u003e This BIP proposes replacing the fixed one megabyte maximum block\n\u003e size with a maximum size that grows over time at a predictable\n\u003e rate.\n\u003e \n\u003e ==Motivation==\n\u003e \n\u003e Transaction volume on the Bitcoin network has been growing, and\n\u003e will soon reach the one-megabyte-every-ten-minutes limit imposed by\n\u003e the one megabyte maximum block size. Increasing the maximum size\n\u003e reduces the impact of that 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 \n\u003e details), the maximum allowed size of a block on the main network\n\u003e shall be calculated 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\n\u003e 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double\n\u003e every 63,072,000 seconds (two years, ignoring leap years), until\n\u003e 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of\n\u003e blocks in between doublings will increase linearly based on the\n\u003e block's timestamp. The maximum size of blocks after 2036-01-06\n\u003e 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 time_double = 60*60*24*365*2 size_start =\n\u003e 8000000 if block_timestamp \u003e= time_start+time_double*10 return\n\u003e size_start * 2^10\n\u003e \n\u003e // Piecewise-linear-between-doublings growth: time_delta =\n\u003e block_timestamp - t_start doublings = time_delta / time_double \n\u003e remainder = time_delta % time_double interpolate = (size_start *\n\u003e 2^doublings * remainder) / time_double max_size = size_start *\n\u003e 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\n\u003e (similar to the technique used in BIP34), but the earliest possible\n\u003e activation time is 2016-01-11 00:00:00 UTC.\n\u003e \n\u003e Activation is achieved when 750 of 1,000 consecutive blocks in the\n\u003e best chain have a version number with bits 3 and 14 set (0x20000004\n\u003e in hex). The activation time will be the timestamp of the 750'th\n\u003e block plus a two week (1,209,600 second) grace period to give any\n\u003e remaining miners or services time to upgrade to support larger\n\u003e blocks. If a supermajority is achieved more than two weeks before\n\u003e 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11\n\u003e 00:00:00 UTC.\n\u003e \n\u003e Block version numbers are used only for activation; once activation\n\u003e is achieved, the maximum block size shall be as described in the \n\u003e specification section, regardless of the version number of the\n\u003e 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\n\u003e current reference implementation code with larger block sizes and\n\u003e receiving feedback from miners stuck behind bandwidth-constrained\n\u003e networks (in particular, Chinese miners behind the Great Firewall\n\u003e of China).\n\u003e \n\u003e The doubling interval was chosen based on long-term growth trends\n\u003e for CPU power, storage, and Internet bandwidth. The 20-year limit\n\u003e was chosen because exponential growth cannot continue forever.\n\u003e \n\u003e Calculations are based on timestamps and not blockchain height\n\u003e because a timestamp is part of every block's header. This allows\n\u003e implementations to know a block's maximum size after they have\n\u003e downloaded it's header, but before downloading any transactions.\n\u003e \n\u003e The deployment plan is taken from Jeff Garzik's proposed BIP100\n\u003e block size increase, and is designed to give miners, merchants,\n\u003e and full-node-running-end-users sufficient time to upgrade to\n\u003e software that supports bigger blocks. A 75% supermajority was\n\u003e chosen so that one large mining pool does not have effective veto\n\u003e power over a blocksize increase. The version number scheme is\n\u003e designed to be compatible with Pieter's Wuille's proposed \"Version\n\u003e 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\n\u003e over this proposal.\n\u003e \n\u003e \n\u003e ==Compatibility==\n\u003e \n\u003e This is a hard-forking change to the Bitcoin protocol; anybody\n\u003e running code that fully validates blocks must upgrade before the\n\u003e activation time or they will risk rejecting a chain containing\n\u003e larger-than-one-megabyte blocks.\n\u003e \n\u003e Simplified Payment Verification software is not affected, unless\n\u003e it makes assumptions about the maximum depth of a transaction's\n\u003e merkle branch based on the minimum size of a transaction and the\n\u003e 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\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175\nCrov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+\nK2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw\nOtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN\nfZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s\nCgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=\n=ft62\n-----END PGP SIGNATURE-----",
"sig": "11fb3bd63f027a061464d537847229f0ad0f89985c9d97801a8bbc401f951623e070b25163f026b1c32d1bbb7561f1ef8a379ea47b5fbb60a678efe867541803"
}