{"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 06:34 PM, Hector Chu via bitcoin-dev wrote:\n\u003e Things apparently aren't bad enough to prevent the majority from \n\u003e clamoring for larger blocks.\n\u003e \n\u003e If the majority agreed that things had got worse till this point, \n\u003e and that this was to be blamed on the block size, they would be \n\u003e campaigning for the other direction. Even yourselves aren't asking \n\u003e for a reduction in the block size, as you know full well that you \n\u003e would be laughed out.\n\u003e \n\nHector, if you could provide data that convinces why 8MB is better\nthan 6.18MB or 1MB then we'd get out of the realm of opinion and\npointless rhetoric that threatens to keep this debate in a quagmire.\nWe'd have actual figures to work with and projections to go by.\n\nBut fetching \"majority\" agreement (where from?) does not cut it for\nsetting Bitcoin on a future path. If we go by that then we'd soon be\ngiving coinbase rewards to users for being \"loyal supporters\" because,\nas a majority, they think that's what they'd like to see.\n\nIf a proposal is demonstrably, and provably, a good idea - and a\ndeveloper consensus agrees - then it should go to testing, and\neventually, code. Other than that it's just conjecture and words\nwithout a research paper and data.\n\nIn the final analysis, do we want Bitcoin to be steered by an\nuninformed and fickle majority, or do we want to use this list as a\nforum to present research proposals containing repeatable, verifiable\nfacts? A progressive process of convincing those most familiar with\nBitcoin's code and operation so they may implement Good Ideas during\nthe next century and after is surely preferable to Vote-my-code-Coin. :)\n\n\n\u003e On 4 August 2015 at 12:27, Pieter Wuille \u003cpieter.wuille at gmail.com \n\u003e \u003cmailto:pieter.wuille at gmail.com\u003e\u003e wrote:\n\u003e \n\u003e I would say that things already demonstrately got terrible. The \n\u003e mining landscape is very centralized, with apparently a majority \n\u003e depending on agreements to trust each other's announced blocks \n\u003e without validation. Full node count is at its historically lowest \n\u003e value in years, and outsourcing of full validation keeps growing.\n\u003e \n\u003e I believe that if the above would have happened overnight, people \n\u003e would have cried wolf. But somehow it happened slow enough, and \n\u003e \"things kept working\".\n\u003e \n\u003e I don't think that this is a good criterion. Bitcoin can \"work\" \n\u003e with gigabyte blocks today, if everyone uses the same few \n\u003e blockchain validation services, the same few online wallets, and \n\u003e mining is done by a cartel that only allows joining after signing\n\u003e a contract so they can sue you if you create an invalid block. Do\n\u003e you think people will then agree that \"things got demonstratebly \n\u003e worse\"?\n\u003e \n\u003e Don't turn Bitcoin into something uninteresting, please.\n\u003e \n\u003e -- Pieter\n\u003e \n\u003e On Aug 4, 2015 1:04 PM, \"Hector Chu via bitcoin-dev\" \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Mike's position is that he wants the block size limit to\n\u003e eventually be removed. That is of course an extreme view.\n\u003e Meanwhile, your view that the block size should be artificially\n\u003e constrained below the organic growth curve (in a way that will\n\u003e penalize a majority of existing and future users) lies at the other\n\u003e extreme. The majority position lies somewhere in between (i.e. a\n\u003e one-time increase to 8MB). This is the position that ultimately\n\u003e matters.\n\u003e \n\u003e If the block size is increased to 8MB and things get demonstrably\n\u003e a whole lot worse, then you will have a solid leg to stand on. In \n\u003e that case we can always do another hard fork later to reduce the \n\u003e block size back to something smaller, and henceforth the block\n\u003e size will never be touched again.\n\u003e \n\u003e On 4 August 2015 at 11:35, Jorge Timón \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn \u003chearn at vinumeris.com \n\u003e \u003cmailto:hearn at vinumeris.com\u003e\u003e wrote:\n\u003e\u003e\u003e How more users or more nodes can bring more miners, or more \n\u003e\u003e\u003e importantly, improve mining decentralization?\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Because the bigger the ecosystem is the more interest there is\n\u003e\u003e in taking part?\n\u003e \n\u003e As explained by Venzen, this is a non-sequitur.\n\u003e \n\u003e\u003e I mean, I guess I don't know how to answer your question.\n\u003e \n\u003e I don't know the answer either, that's fine. It's the opposite \n\u003e question that I've been insistently repeating and you've been \n\u003e (consciously or not) consistently evading. But that's also fine \n\u003e because I believe you finally answer it a few lines below.\n\u003e \n\u003e\u003e When Bitcoin was new it had almost no users and almost no\n\u003e\u003e miners. Now there are millions of users and factories producing\n\u003e\u003e ASICs just for Bitcoin.\n\u003e \n\u003e The emergence of a btc price enabled the emergence of professional\n\u003e  miners, which in turn enabled the emergence of sha256d-specialized\n\u003e  hardware production companies. Nothing surprising there. By no \n\u003e means it consitutes an example of how a bigger consensus sizes can \n\u003e cause less mining centralization.\n\u003e \n\u003e\u003e Surely the correlation is obvious?\n\u003e \n\u003e Correlation does not imply causation. I will better leave it at \n\u003e that...\n\u003e \n\u003e\u003e\u003e I'm sorry, but until there's a simulation that I can run with \n\u003e\u003e\u003e different sizes' testchains (for example using #6382) to \n\u003e\u003e\u003e somehow compare them, I will consider any value arbitrary.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e Gavin did run simulations. 20mb isn't arbitrary, the process \n\u003e\u003e behind it was well documented here:\n\u003e\u003e \n\u003e\u003e http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized\n\u003e\n\u003e\u003e\n\u003e\u003e \n\u003e \n\u003e\u003e I chose 20MB as a reasonable block size to target because 170 \n\u003e\u003e gigabytes per month comfortably fits into the typical 250-300 \n\u003e\u003e gigabytes per month data cap– so you can run a full node from \n\u003e\u003e home on a “pretty good” broadband plan.\n\u003e\u003e \n\u003e\u003e Did you think 20mb was picked randomly?\n\u003e \n\u003e No, I think 20 MB was chosen very optimistically, considering 3rd \n\u003e party services rates (not the same service as self-hosting) in the\n\u003e  so-called \"first world\". And then 20 MB goes to 20 GB, again with\n\u003e  optimistic and by no means scientific expectations.\n\u003e \n\u003e But where the number comes from it's not really what I'm demaning,\n\u003e  what I want is some criterion that can tell you that a given size\n\u003e  would be \"too centralized\" but another one isn't. I haven't read \n\u003e any analysis on why 8GB is a better option than 7GB and 9GB for a \n\u003e given criterion (nor one declaring 20 GB a winner over 19 GB or 21 \n\u003e GB). A simulation test passing 20 GB but not 21 GB would make it \n\u003e far less arbitrary.\n\u003e \n\u003e\u003e\u003e Agreed on the first sentence, I'm just saying that the \n\u003e\u003e\u003e influence of the blocksize in that function is monotonic: with \n\u003e\u003e\u003e bigger sizes, equal or worse mining centralization.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e I have a hard time agreeing with this because I've seen Bitcoin \n\u003e\u003e go from blocks that were often empty to blocks that are often \n\u003e\u003e full, and in this time the number of miners and hash power on\n\u003e\u003e the network has gone up a huge amount too.\n\u003e \n\u003e I'm of course talking about consensus maximum blocksize, not about\n\u003e  actual blocksize. Yes, again, when mining becomes profitable, \n\u003e economic actors tend to appear and get those profits. But don't \n\u003e confuse total hashrate improvements with an \"increase in the\n\u003e number of miners\" or with mining decentralization.\n\u003e \n\u003e\u003e You can argue that a miner doesn't count if they pool mine. But \n\u003e\u003e if a miner mines on a pool that uses exactly the same software \n\u003e\u003e and settings as the miner would have done anyway, then it makes \n\u003e\u003e no difference. Miners can switch between pools to find one that \n\u003e\u003e works the way they like, so whilst less pooling or more \n\u003e\u003e decentralised pools would be nice (e.g. getblocktemplate), and \n\u003e\u003e I've written about how to push it forward before, I still say \n\u003e\u003e there are many more miners than in the past.\n\u003e\u003e \n\u003e\u003e If I had to pick between two changes to improve mining \n\u003e\u003e decentralisation:\n\u003e\u003e \n\u003e\u003e 1) Lower block size\n\u003e \n\u003e Finally, I think you finally answered my repetitive question here.\n\u003e  If I say \"Mike Hearn understands that the consensus block size \n\u003e maximum rule is a tool for limitting mining centralization\" I'm not\n\u003e putting words in your mouth, right? I think many users advocating\n\u003e for an increase in the consensus limit don't understand this, which\n\u003e is extremely unfortunate for the debate.\n\u003e \n\u003e\u003e 2) Finishing, documenting, and making the UX really slick for a \n\u003e\u003e getblocktemplate based decentralised mining pool\n\u003e\u003e \n\u003e\u003e then I'd pick (2) in a heartbeat. I think it'd be a lot more \n\u003e\u003e effective.\n\u003e \n\u003e Great! Maybe after 2 mining centralization improves so much that \n\u003e we're confortable not only not lowering it but rather increasing \n\u003e it.\n\u003e \n\u003e\u003e\u003e you should be consequently advocating for full removal of the \n\u003e\u003e\u003e limit rather than changes towards bigger arbitrary values.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e I did toy with that idea a while ago. Of course there can not \n\u003e\u003e really be no limit at all because the code assumes blocks fit \n\u003e\u003e into RAM/swap, and nodes would just end up ignoring blocks they \n\u003e\u003e couldn't download in time anyway. There is obviously a physical \n\u003e\u003e limit somewhere.\n\u003e \n\u003e Did the fact that you \"understand that the consensus block size \n\u003e maximum rule is a tool for limitting mining centralization\" \n\u003e influenced your rejection of that idea at all?\n\u003e \n\u003e\u003e But it is easier to find common ground with others by \n\u003e\u003e compromising. Is 8mb better than no limit? I don't know and I \n\u003e\u003e don't care much:  I think Bitcoin adoption is a slow, hard \n\u003e\u003e process and we'll be lucky to increase average usage 8x over the \n\u003e\u003e next couple of years. So if 8mb+ is better for others, that's OK \n\u003e\u003e by me.\n\u003e \n\u003e The only way that \"not caring much whther we have a consensus\n\u003e limit or not\" and \"understand that the consensus block size maximum\n\u003e rule is a tool for limitting mining centralization\" at the same\n\u003e time is by not caring about mining centralization at all. Is that\n\u003e your position?\n\u003e \n\u003e If you don't care about having a limit but you don't want to limit\n\u003e  transaction volume, then ++current_size will ALWAYs be your \n\u003e \"compromise position\" and no blocksize increase will ever be enough\n\u003e until the limit is completely removed. Is that your position?\n\u003e \n\u003e\u003e Re: exchange profit. You can pick some other useful service \n\u003e\u003e provider if you like. Payment processors or cold storage \n\u003e\u003e providers or the TREZOR manufacturers or whoever.\n\u003e \n\u003e Yes, and I believe the same points stand.\n\u003e \n\u003e\u003e My point is you can't have a tiny high-value-transactions only \n\u003e\u003e currency AND all the useful infrastructure that the Bitcoin \n\u003e\u003e community is making. It's a contradiction. And without the \n\u003e\u003e infrastructure bitcoin ceases to be interesting even to people \n\u003e\u003e who are willing to pay huge sums to use it.\n\u003e \n\u003e You keep talking about \"high-value-transactions-only\" like if \n\u003e non-urgent transaction fees rising from zero to, say, 1 satoshi, \n\u003e would automatically result in that \"high-value-transactions-only\" \n\u003e Bitcoin. Please, stop talking as if someone was proposing a \n\u003e \"high-value-transactions-only\" Bitcoin. That may happen but nobody\n\u003e  really knows. If it happens it may not be bad thing necessarily \n\u003e (ie bitcoin microtransactions can still happen using trustless \n\u003e payment channels and x is still cheaper than x% for any transacted \n\u003e value higher than 100) but that's really not what we're talking \n\u003e about here so it seems distraction that can only help further \n\u003e polirizing this discussion.\n\u003e \n\u003e What we're talking about here is that hitting the limit would \n\u003e (hopefully) make miners start caring about fees. Enough that they \n\u003e stop being irrational about free transactions. If both things \n\u003e happen, non-urgent transaction fees will likely rise (as said, \n\u003e above zero).\n\u003e \n\u003e You think that would be a catastrophe for adoption and I disagree.\n\u003e  But (as Pieter has repeatedly explained) for any size there will \n\u003e be use cases that will be eventually priced out. So when rising \n\u003e this consensus limit, not increasing centralization should be the \n\u003e priority and the potential impact in market fees a much more \n\u003e secondary concern. Do you agree with this?\n\u003e \n\u003e I'm sure there are many intermediate positions between \"caring more\n\u003e about mining centralization than market fees when deciding about a\n\u003e consensus rule that limits mining centralization\" and \"not caring\n\u003e about mining centralization at all\". I really don't want to put\n\u003e words in your mouth, but I honestly don't know what your position\n\u003e is. I don't really know how else can I ask the same question: you\n\u003e don't care the consensus maximum blocksize rule being here at all\n\u003e or not (you just said that). Is it because you don't think it\n\u003e limits mining centralization or because you don't care about\n\u003e limiting mining centralization with consensus rules at all? \n\u003e _______________________________________________ bitcoin-dev\n\u003e mailing list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev\n\u003e mailing list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev\n\u003e mailing list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVwKvEAAoJEGwAhlQc8H1m2g4H/i3jcap3C1mt5hG964EWlF42\nMC6/P23MWI6o5AO7Ugz6m35IDO+ZfegY3VlAmAaq0KSwKEoZSWV/FIPQPpVOCGeP\nCdIGw4M+Q//kRBaxNEnfC3gM7IYHRFfOEwZtVsda5vriem+Yjb4Fk+YoXyONI2j1\n0GqmPAIJ5+eA1H/t541/lUDHVzLyymlsWX34MIjX1BWnKQaap+eaMHucu+DrcRHd\nGltkKrqRQ/Hngv7PtaQGTPjUHrQglHISl6BMXNMbmxoEHg2RfrRwifiJGnDmEty6\nl/Yve6slLtaQA+SIyAun79SUU5+QJOOWDxU2PlXQTRldx+0YQJ60L0GanQ5CHc8=\n=EarG\n-----END PGP SIGNATURE-----"}