{"type":"rich","version":"1.0","author_name":"npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpf","author_url":"https://nostr.ae/npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpf","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-04\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n\n\nOn 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:\n\u003e On 4 August 2015 at 12:59, Jorge Timón \u003cjtimon at jtimon.cc \n\u003e \u003cmailto:jtimon at jtimon.cc\u003e\u003e wrote:\n\n\u003e So if you say 8, I must ask, why not 9? Why 9 MB is not safe for \n\u003e mining centralization but 8 MB is?\n\u003e \n\u003e \n\u003e 8MB has simply been the focal point for this debate. 9MB is also \n\u003e safe if 8MB is, but I suppose the opponents will be even less\n\u003e happy with 9 than with 8, and we don't want to unnecessarily\n\u003e increase the conflict.\n\u003e \n\nJorge will answer for himself, but you know that saying \"9MB is also\nsafe if 8MB is\" blows your position.\n\nDo you, or me, or XT know that 8MB is \"safe\"? You say 9MB must then\nalso be \"safe\" - there has been no fact for me to grasp and from which\nto tell a Bitcoin trading whale group: \"here's the bottom line: this\nis what it means and these are the implications.\" They hold\nsignificant amounts of bitcoin and want to see a plan, and a strategy\nbased on facts. I can assure you, they're not going to XT, it lacks\nboth a strategy and the seasoned developers present here.\n\n\u003e It seems like the rationale it's always \"the bigger the better\" and\n\u003e the only limitation is what a few people concerned with mining \n\u003e centralization (while they still have time to discuss this) are \n\u003e willing to accept. If that's the case, then there won't be \n\u003e effectively any limit in the long term and Bitcoin will probably \n\u003e fail in its decentralization goals.\n\u003e \n\u003e \n\u003e A one-time increase to 8MB is safer than a dynamically growing \n\u003e limit over time for exactly this reason. Admittedly whenever the \n\u003e next debate to increase the block size over 8MB happens it will be \n\u003e even more painful and non-obvious, but that is the safety check to \n\u003e prevent unbounded block size increase.\n\nYou're articulate and you raise valid issues, but your judgment of\n\"safer\" is not based on anything you or this list can refer to as a\ncomparator.\n\nIt seems you want 8MB for some ideological reason but if you examine\nyour motive and compare it to the facts, you'll find that many people\nin this list are ultimately correct in saying that:\n\nWhatever blocksize is set to, demand will soon fill it.\n\nThis is the nature of resource supply inflation - some business plan\nwill spot the opportunity and exploit it, colonize it and then we deal\nwith that, with some big-girls'-blouses exclaiming: \"if we don't give\nthem what they want they're all going to leave to XT or ZT!\"\n\nEven though XT and ZT perfectly fulfill the needs of certain ambitious\nbusinesses, the creators would rather see it happen on Core's\nblockchain. Else why do they still come posit arguments here?\n\nFortunately, unlike the principle that applies in finance capital,\nBitcoin capacity supply doesn't have be increased on demand (not\nwithout rigorous testing and evaluation) plus there is no maxim here\nthat \"the customer is always right\". The maxim is \"be your own bank\" -\nduring some periods it might be a slow bank but it _will_ remain\ndecentralized and it _will_ remain your own - not compromised to some\nbig business or mining cartel.\n\nWe want to compromise to science and reason, not profit motive or\ndemocratic lobbying, right?\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu\nOWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by\nLMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv\nfyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb\nS/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i\nacqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=\n=WhnR\n-----END PGP SIGNATURE-----"}