{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-07\n📝 Original message:On Thu, May 7, 2015 at 12:12 AM, Matt Corallo \u003cbitcoin-list at bluematt.me\u003e\nwrote:\n\n\u003e Recently there has been a flurry of posts by Gavin at\n\u003e http://gavinandresen.svbtle.com/ which advocate strongly for increasing\n\u003e the maximum block size. However, there hasnt been any discussion on this\n\u003e mailing list in several years as far as I can tell.\n\u003e\n\nThanks for bringing this up. I'll try to keep my arguments brief, to avoid\na long wall of text. I may be re-iterating some things that have been said\nbefore, though.\n\nI am - in general - in favor of increasing the size blocks: as technology\ngrows, there is no reason why the systems built on them can't scale\nproportionally. I have so far not commented much about this, in a hope to\navoid getting into a public debate, but the way seems to be going now,\nworries me greatly.\n\n* Controversial hard forks. I hope the mailing list here today already\nproves it is a controversial issue. Independent of personal opinions pro or\nagainst, I don't think we can do a hard fork that is controversial in\nnature. Either the result is effectively a fork, and pre-existing coins can\nbe spent once on both sides (effectively failing Bitcoin's primary\npurpose), or the result is one side forced to upgrade to something they\ndislike - effectively giving a power to developers they should never have.\nQuoting someone: \"I did not sign up to be part of a central banker's\ncommittee\".\n\n* The reason for increasing is \"need\". If \"we need more space in blocks\" is\nthe reason to do an upgrade, it won't stop after 20 MB. There is nothing\nfundamental possible with 20 MB blocks that isn't with 1 MB blocks.\nChangetip does not put their microtransactions on the chain, not with 1 MB,\nand I doubt they would with 20 MB blocks. The reason for increase should be\n\"because we choose to accept the trade-offs\".\n\n* Misrepresentation of the trade-offs. You can argue all you want that none\nof the effects of larger blocks are particularly damaging, so everything is\nfine. They will damage something (see below for details), and we should\nanalyze these effects, and be honest about them, and present them as a\ntrade-off made we choose to make to scale the system better. If you just\nask people if they want more transactions, of course you'll hear yes. If\nyou ask people if they want to pay less taxes, I'm sure the vast majority\nwill agree as well.\n\n* Miner centralization. There is currently, as far as I know, no technology\nthat can relay and validate 20 MB blocks across the planet, in a manner\nfast enough to avoid very significant costs to mining. There is work in\nprogress on this (including Gavin's IBLT-based relay, or Greg's block\nnetwork coding), but I don't think we should be basing the future of the\neconomics of the system on undemonstrated ideas. Without those (or even\nwith), the result may be that miners self-limit the size of their blocks to\npropagate faster, but if this happens, larger, better-connected, and more\ncentrally-located groups of miners gain a competitive advantage by being\nable to produce larger blocks. I would like to point out that there is\nnothing evil about this - a simple feedback to determine an optimal block\nsize for an individual miner will result in larger blocks for better\nconnected hash power. If we do not want miners to have this ability, \"we\"\n(as in: those using full nodes) should demand limitations that prevent it.\nOne such limitation is a block size limit (whatever it is).\n\n* Ability to use a full node. I very much dislike the trend of people\nsaying \"we need to encourage people to run full nodes, in order to make the\nnetwork more decentralized\". Running 1000 nodes which are otherwise unused\nonly gives some better ability for full nodes to download the block chain,\nor for SPV nodes to learn about transactions (or be Sybil-attacked...).\nHowever, *using* a full node for validating your business (or personal!)\ntransactions empowers you to using a financial system that requires less\ntrust in *anyone* (not even in a decentralized group of peers) than\nanything else. Moreover, using a full node is what given you power of the\nsystems' rules, as anyone who wants to change it now needs to convince you\nto upgrade. And yes, 20 MB blocks will change people's ability to use full\nnodes, even if the costs are small.\n\n* Skewed incentives for improvements. I think I can personally say that I'm\nresponsible for most of the past years' performance improvements in Bitcoin\nCore. And there is a lot of room for improvement left there - things like\nsilly waiting loops, single-threaded network processing, huge memory sinks,\nlock contention, ... which in my opinion don't nearly get the attention\nthey deserve. This is in addition to more pervasive changes like optimizing\nthe block transfer protocol, support for orthogonal systems with a\ndifferent security/scalability trade-off like Lightning, making full\nvalidation optional, ... Call me cynical, but without actual pressure to\nwork on these, I doubt much will change. Increasing the size of blocks now\nwill simply make it cheap enough to continue business as usual for a while\n- while forcing a massive cost increase (and not just a monetary one) on\nthe entire ecosystem.\n\n* Fees and long-term incentives. I put this last, not because I don't think\nit is not serious, but because I don't understand nearly enough about it.\nI'll let others comment.\n\nI don't think 1 MB is optimal. Block size is a compromise between\nscalability of transactions and verifiability of the system. A system with\n10 transactions per day that is verifiable by a pocket calculator is not\nuseful, as it would only serve a few large bank's settlements. A system\nwhich can deal with every coffee bought on the planet, but requires a\nGoogle-scale data center to verify is also not useful, as it would be\ntrivially out-competed by a VISA-like design. The usefulness needs in a\nbalance, and there is no optimal choice for everyone. We can choose where\nthat balance lies, but we must accept that this is done as a trade-off, and\nthat that trade-off will have costs such as hardware costs, decreasing\nanonymity, less independence, smaller target audience for people able to\nfully validate, ...\n\nChoose wisely.\n\nThanks for reading this,\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/29c77115/attachment.html\u003e"}