rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2015-05-07 📝 Original message:On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me> wrote: > Recently there has been a flurry of posts by Gavin at > http://gavinandresen.svbtle.com/ which advocate strongly for increasing > the maximum block size. However, there hasnt been any discussion on this > mailing list in several years as far as I can tell. > Thanks for bringing this up. I'll try to keep my arguments brief, to avoid a long wall of text. I may be re-iterating some things that have been said before, though. I am - in general - in favor of increasing the size blocks: as technology grows, there is no reason why the systems built on them can't scale proportionally. I have so far not commented much about this, in a hope to avoid getting into a public debate, but the way seems to be going now, worries me greatly. * Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee". * The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks. Changetip does not put their microtransactions on the chain, not with 1 MB, and I doubt they would with 20 MB blocks. The reason for increase should be "because we choose to accept the trade-offs". * Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well. * Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is). * Ability to use a full node. I very much dislike the trend of people saying "we need to encourage people to run full nodes, in order to make the network more decentralized". Running 1000 nodes which are otherwise unused only gives some better ability for full nodes to download the block chain, or for SPV nodes to learn about transactions (or be Sybil-attacked...). However, *using* a full node for validating your business (or personal!) transactions empowers you to using a financial system that requires less trust in *anyone* (not even in a decentralized group of peers) than anything else. Moreover, using a full node is what given you power of the systems' rules, as anyone who wants to change it now needs to convince you to upgrade. And yes, 20 MB blocks will change people's ability to use full nodes, even if the costs are small. * Skewed incentives for improvements. I think I can personally say that I'm responsible for most of the past years' performance improvements in Bitcoin Core. And there is a lot of room for improvement left there - things like silly waiting loops, single-threaded network processing, huge memory sinks, lock contention, ... which in my opinion don't nearly get the attention they deserve. This is in addition to more pervasive changes like optimizing the block transfer protocol, support for orthogonal systems with a different security/scalability trade-off like Lightning, making full validation optional, ... Call me cynical, but without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem. * Fees and long-term incentives. I put this last, not because I don't think it is not serious, but because I don't understand nearly enough about it. I'll let others comment. I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ... Choose wisely. Thanks for reading this, -- Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/29c77115/attachment.html>