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