{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-04\n📝 Original message:On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn \u003chearn at vinumeris.com\u003e wrote:\n\u003e\u003e How more users or more nodes can bring more miners, or more importantly,\n\u003e\u003e improve mining decentralization?\n\u003e\n\u003e\n\u003e Because the bigger the ecosystem is the more interest there is in taking\n\u003e part?\n\nAs explained by Venzen, this is a non-sequitur.\n\n\u003e I mean, I guess I don't know how to answer your question.\n\nI don't know the answer either, that's fine. It's the opposite\nquestion that I've been insistently repeating and you've been\n(consciously or not) consistently evading.\nBut that's also fine because I believe you finally answer it a few lines below.\n\n\u003e When Bitcoin was\n\u003e new it had almost no users and almost no miners. Now there are millions of\n\u003e users and factories producing ASICs just for Bitcoin.\n\nThe emergence of a btc price enabled the emergence of professional\nminers, which in turn enabled the emergence of sha256d-specialized\nhardware production companies.\nNothing surprising there.\nBy no means it consitutes an example of how a bigger consensus sizes\ncan cause less mining centralization.\n\n\u003e Surely the correlation is obvious?\n\nCorrelation does not imply causation. I will better leave it at that...\n\n\u003e\u003e I'm sorry, but until there's a simulation that I can run with different\n\u003e\u003e sizes' testchains (for example using #6382) to somehow compare them, I will\n\u003e\u003e consider any value arbitrary.\n\u003e\n\u003e\n\u003e Gavin did run simulations. 20mb isn't arbitrary, the process behind it was\n\u003e well documented here:\n\u003e\n\u003e http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized\n\u003e\n\u003e I chose 20MB as a reasonable block size to target because 170 gigabytes per\n\u003e month comfortably fits into the typical 250-300 gigabytes per month data\n\u003e cap– so you can run a full node from home on a “pretty good” broadband plan.\n\u003e\n\u003e Did you think 20mb was picked randomly?\n\nNo, I think 20 MB was chosen very optimistically, considering 3rd\nparty services rates (not the same service as self-hosting) in the\nso-called \"first world\". And then 20 MB goes to 20 GB, again with\noptimistic and by no means scientific expectations.\n\nBut where the number comes from it's not really what I'm demaning,\nwhat I want is some criterion that can tell you that a given size\nwould be \"too centralized\" but another one isn't.\nI haven't read any analysis on why 8GB is a better option than 7GB and\n9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB\nor 21 GB).\nA simulation test passing 20 GB but not 21 GB would make it far less arbitrary.\n\n\u003e\u003e Agreed on the first sentence, I'm just saying that the influence of\n\u003e\u003e the blocksize in that function is monotonic: with bigger sizes, equal\n\u003e\u003e or worse mining centralization.\n\u003e\n\u003e\n\u003e I have a hard time agreeing with this because I've seen Bitcoin go from\n\u003e blocks that were often empty to blocks that are often full, and in this time\n\u003e the number of miners and hash power on the network has gone up a huge amount\n\u003e too.\n\nI'm of course talking about consensus maximum blocksize, not about\nactual blocksize.\nYes, again, when mining becomes profitable, economic actors tend to\nappear and get those profits.\nBut don't confuse total hashrate improvements with an \"increase in the\nnumber of miners\" or with mining decentralization.\n\n\u003e You can argue that a miner doesn't count if they pool mine. But if a miner\n\u003e mines on a pool that uses exactly the same software and settings as the\n\u003e miner would have done anyway, then it makes no difference. Miners can switch\n\u003e between pools to find one that works the way they like, so whilst less\n\u003e pooling or more decentralised pools would be nice (e.g. getblocktemplate),\n\u003e and I've written about how to push it forward before, I still say there are\n\u003e many more miners than in the past.\n\u003e\n\u003e If I had to pick between two changes to improve mining decentralisation:\n\u003e\n\u003e 1) Lower block size\n\nFinally, I think you finally answered my repetitive question here.\nIf I say \"Mike Hearn understands that the consensus block size maximum\nrule is a tool for limitting mining centralization\" I'm not putting\nwords in your mouth, right?\nI think many users advocating for an increase in the consensus limit\ndon't understand this, which is extremely unfortunate for the debate.\n\n\u003e 2) Finishing, documenting, and making the UX really slick for a\n\u003e getblocktemplate based decentralised mining pool\n\u003e\n\u003e then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.\n\nGreat! Maybe after 2 mining centralization improves so much that we're\nconfortable not only not lowering it but rather increasing it.\n\n\u003e\u003e you should be consequently advocating for full removal of the limit rather\n\u003e\u003e than changes towards bigger arbitrary values.\n\u003e\n\u003e\n\u003e I did toy with that idea a while ago. Of course there can not really be no\n\u003e limit at all because the code assumes blocks fit into RAM/swap, and nodes\n\u003e would just end up ignoring blocks they couldn't download in time anyway.\n\u003e There is obviously a physical limit somewhere.\n\nDid the fact that you \"understand that the consensus block size\nmaximum rule is a tool for limitting mining centralization\" influenced\nyour rejection of that idea at all?\n\n\u003e But it is easier to find common ground with others by compromising. Is 8mb\n\u003e better than no limit? I don't know and I don't care much:  I think Bitcoin\n\u003e adoption is a slow, hard process and we'll be lucky to increase average\n\u003e usage 8x over the next couple of years. So if 8mb+ is better for others,\n\u003e that's OK by me.\n\nThe only way that \"not caring much whther we have a consensus limit or\nnot\" and \"understand that the consensus block size maximum rule is a\ntool for limitting mining centralization\" at the same time is by not\ncaring about mining centralization at all.\nIs that your position?\n\nIf you don't care about having a limit but you don't want to limit\ntransaction volume, then ++current_size will ALWAYs be your\n\"compromise position\" and no blocksize increase will ever be enough\nuntil the limit is completely removed.\nIs that your position?\n\n\u003e Re: exchange profit. You can pick some other useful service provider if you\n\u003e like. Payment processors or cold storage providers or the TREZOR\n\u003e manufacturers or whoever.\n\nYes, and I believe the same points stand.\n\n\u003e My point is you can't have a tiny high-value-transactions only currency AND\n\u003e all the useful infrastructure that the Bitcoin community is making. It's a\n\u003e contradiction. And without the infrastructure bitcoin ceases to be\n\u003e interesting even to people who are willing to pay huge sums to use it.\n\nYou keep talking about \"high-value-transactions-only\" like if\nnon-urgent transaction fees rising from zero to, say, 1 satoshi, would\nautomatically result in that \"high-value-transactions-only\" Bitcoin.\nPlease, stop talking as if someone was proposing a\n\"high-value-transactions-only\" Bitcoin. That may happen but nobody\nreally knows. If it happens it may not be bad thing necessarily (ie\nbitcoin microtransactions can still happen using trustless payment\nchannels and x is still cheaper than x% for any transacted value\nhigher than 100) but that's really not what we're talking about here\nso it seems distraction that can only help further polirizing this\ndiscussion.\n\nWhat we're talking about here is that hitting the limit would\n(hopefully) make miners start caring about fees. Enough that they stop\nbeing irrational about free transactions. If both things happen,\nnon-urgent transaction fees will likely rise (as said, above zero).\n\nYou think that would be a catastrophe for adoption and I disagree.\nBut (as Pieter has repeatedly explained) for any size there will be\nuse cases that will be eventually priced out.\nSo when rising this consensus limit, not increasing centralization\nshould be the priority and the potential impact in market fees a much\nmore secondary concern.\nDo you agree with this?\n\nI'm sure there are many intermediate positions between \"caring more\nabout mining centralization than market fees when deciding about a\nconsensus rule that limits mining centralization\" and \"not caring\nabout mining centralization at all\".\nI really don't want to put words in your mouth, but I honestly don't\nknow what your position is.\nI don't really know how else can I ask the same question: you don't\ncare the consensus maximum blocksize rule being here at all or not\n(you just said that).\nIs it because you don't think it limits mining centralization or\nbecause you don't care about limiting mining centralization with\nconsensus rules at all?"}