{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-23\n📝 Original message:On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:\n\u003e \u003e ==Rationale==\n\u003e \u003e\n\u003e \u003e The initial size of 8,000,000 bytes was chosen after testing the current\n\u003e \u003e reference implementation code with larger block sizes and receiving\n\u003e \u003e feedback from miners stuck behind bandwidth-constrained networks (in\n\u003e \u003e particular, Chinese miners behind the Great Firewall of China).\n\u003e \u003e\n\u003e \u003e The doubling interval was chosen based on long-term growth trends for CPU\n\u003e \u003e power, storage, and Internet bandwidth. The 20-year limit was chosen\n\u003e \u003e because exponential growth cannot continue forever.\n\u003e\n\u003e Wladimir noted that 'The original presented intention of block size\n\u003e increase was a one-time \"scaling\" to grant time for more decentralizing\n\u003e solutions to develop'\n\u003e\n\u003e Comments?\n\u003e\n\nConsensus is that this process is too painful to go through once a year.  I\nagree.\n\nIf you disagree and would like to see a Blocksize Council meet once a year\nto issue a decree on what the maximum block size shall be for the next\nyear, then propose a process for who gets to sit on the Council and how\ntheir decrees are enforced.....\n\n\n\u003e\n\u003e In particular, if bandwidth scaling doesn't go according to your plan,\n\u003e e.g. the exponential exponent is too large, perhaps due to technological\n\u003e growth not keeping pace, or the political realities of actual bandwidth\n\u003e deployment making theoretical technological growth irrelevant, what\n\u003e mechanism will prevent centralization? (if any)\n\n\nSimulations show that:\n\nLatency/bandwidth matter for miners.  Low latency, high bandwidth is\nbetter. However, miners with bad connectivity can simply create smaller\nblocks...\n\n... until transaction fees become significant.  But by the time that\nhappens, protocol optimizations of block propagation will make the block\nsize an insignificant term in the \"how profitable is it to mine in THIS\nparticular place on the Internet / part of the world\" equation.\n\n(Reference:\nhttps://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08224.html\n)\n\nSo: for the immediate future, there is no problem. And in the long term,\nthere is no problem.\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/2e36743c/attachment.html\u003e"}