{"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-05\n📝 Original message:On Wed, Aug 5, 2015 at 9:29 AM, Elliot Olds \u003celliot.olds at gmail.com\u003e wrote:\n\u003e On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Also I don't think \"hitting the limit\" must be necessarily harmful and\n\u003e\u003e if it is, I don't understand why hitting it at 1MB will be more\n\u003e\u003e harmful than hitting it at 2MB, 8MB or 8GB.\n\u003e\n\u003e\n\u003e I don't think merely hitting the limit is bad. The level of tx fees in\n\u003e equilibrium give some clue as to the level of harm being done. If fees are\n\u003e at $5/tx at 1MB, it's about as bad as if fees are at $5/tx at 4MB.\n\nThis is a much more reasonable position. I wish this had been starting\npoint of this discussion instead of \"the block size limit must be\nincreased as soon as possible or bitcoin will fail\".\nIf the only fear about not increasing the block size fast enough is\nthat fees may rise, pieter wouldn't had to repeatedly explain that for\nany reasonable block size some use case may fill the blocks rapidly.\n\n\u003e\u003e There is NO criterion based on mining centralization to decide between\n\u003e\u003e 2 sizes in favor of the small one.\n\u003e\u003e It seems like the rationale it's always \"the bigger the better\" and\n\u003e\u003e the only limitation is what a few people concerned with mining\n\u003e\u003e centralization (while they still have time to discuss this) are\n\u003e\u003e willing to accept. If that's the case, then there won't be effectively\n\u003e\u003e any limit in the long term and Bitcoin will probably fail in its\n\u003e\u003e decentralization goals.\n\u003e\u003e I think its the proponents of a blocksize change who should propose\n\u003e\u003e such a criterion and now they have the tools to simulate different\n\u003e\u003e block sizes.\n\u003e\n\u003e\n\u003e In the absence of harder data, it might be interesting to use these\n\u003e simulations to graph centralization pressure as a function of bandwidth cost\n\u003e over time (or other historical variables that affect centralization). For\n\u003e instance, look at how high centralization pressure was in 2009 according to\n\u003e the simulations, given how cheap/available bandwidth was then, compared to\n\u003e 2010, 2011, etc. Then we could figure out: given today's bandwidth\n\u003e situation, what size blocks right now would give us the same centralization\n\u003e pressure that we had in 2011, 2012, 2013, etc?\n\u003e\n\u003e Of course this doesn't mean we should blindly assume that the level of\n\u003e centralization pressure in 2012 was acceptable, and therefore any block size\n\u003e increase that results in the same amount of pressure now should be\n\u003e acceptable. But it might lead to a more productive discussion.\n\nThis sounds good overall but I'm afraid you are oversimplifying some things.\nCentralization pressure not only comes from global average bandwidth\ncosts and block propagation times is not the only concern.\nHere's an extreme example: [1]\nBut anyway, yes, I agree, ANY metric would be better than nothing (the\ncurrent situation).\n\n\u003e\u003e I want us to simulate many blocksizes before rushing into a decision\n\u003e\u003e (specially because I disagree that taking a decision there is urgent\n\u003e\u003e in the first place).\n\u003e\n\u003e\n\u003e IMO it is not urgent if the core devs are committed to reacting to a huge\n\u003e spike in tx fees with a modest block size increase in a relatively short\n\u003e time frame, if they judge the centralization risks of that increase to be\n\u003e small. Greg Maxwell posted on reddit a while back something to the effect of\n\u003e \"the big block advocates are overstating the urgency of the block size\n\u003e increase, because if there was actually a situation that required us to\n\u003e increase block size, we could make the increase when it was actually\n\u003e needed.\" I found that somewhat persuasive, but I am concerned that I haven't\n\u003e seen any discussion of what the \"let's wait for now\" camp would consider a\n\u003e valid reason to increase block size in the short term, and how they'd make\n\u003e the tradeoff with tx fees or whatever else was necessitating the increase.\n\nGiven that for any non-absurdly-big size some transactions will\neventually be priced out, and that the consensus rule serves for\nlimiting mining centralization (and more indirectly centralization in\ngeneral) and not about trying to set a given average transaction fee,\nI think the current level of mining centralization will always be more\nrelevant than the current fee level when discussing any change to the\nconsensus rule to limit centralization (at any point in time).\nIn other words, the question \"can we change this without important\nrisks of destroying the decentralized properties of the system in the\nshort or long run?\" should be always more important than \"is there a\nconcerning rise in fees to motivate this change at all?\".\n\n\u003e Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow knew\n\u003e with certainty that increasing to 4MB would result in a 20 cent/tx\n\u003e equilibrium that would last for a year (otherwise fees would stay around $5\n\u003e for that year), would you be in favor of an increase to 4MB?\n\nAs said, I would always consider the centralization risks first: I'd\nrather have a $5/tx decentralized Bitcoin than a Bitcoin with free\ntransactions but effectively validated (when they validate blocks they\nmine on top of) by around 10 miners, specially if only 3 of them could\neasily collude to censor transactions [orphaning any block that\ndoesn't censor in the same manner]. Sadly I have no choice, the later\nis what we have right now. And reducing the block size can't guarantee\nthat the situation will get better or even that fees could rise to\n$5/tx (we just don't have that demand, not that it is a goal for\nanyone). All I know is that increasing the block size *could*\n(conditional, not necessarily, I don't know in which cases, I don't\nthink anybody does) make things even worse.\n\nOn the other hand, I could understand people getting worried if fees\nwhere as high as $5/tx or even 20 cent/tx but we're very far away from\nthat case. How can low subsidies (a certainty) be \"too far in the\nfuture to worry about it\" but $5/tx, 20 cent/tx or even 5 cent/tx an\nurgent concern? For all I know, 5 cent/tx may not happen in the next\n25 years: it may never happen. And if it happens, to me it will be a\nsymptom of Bitcoin success, even for others it means that Bitcoin has\nbecome a \"high value settlement network\".\nTo the question\n\n- At which minimum mining fee rate will you urge others to change the\nconsensus rules to increase the block size?\n\nI'm very sorry, but my answer is:\n\n- I honestly don't know, that may never happen.\n\nWhat I can tell you is this: I will never be worried about \"too high\nfees\" while the fees remain at 0 (null, zero, nothing, cero, nada,\nzilch).\nThat's right, no matter what wallet's defaults chose for their users,\nno matter what the minimum relay fee policy does to the \"fee market\"\nand how much urgent transactions pay in fees; the fact remains that in\npractice non-urgent transactions usually (when the raw transaction's\nstructure it's appropriate) don't have to pay fees.\n\nI'm still missing an answer from the \"big blocks size side\" to the\nfollowing question (which I have insistently repeated with various\npermutations):\n\nIf \"not now\" when will it be a good time to let fees rise above zero?\nAfter the next subsidy halving? After 4 more subsidy halvings (ie\nabout 13 years from now, subsidy = 1.5625 btc/block )? After your\ngrandmother abandons her national currency and uses Bitcoin for\neverything? Never?\n\nANY answer (maybe with the exception of the last one) would be less\nworrying than silence.\n\n\u003e For those familiar with the distinction between near/far mode thinking\n\u003e popularized by Robin Hanson: focusing on concrete examples like this\n\u003e encourages problem solving and consensus, and focusing on abstract\n\u003e principles (like decentralization vs. usability in general) leads to people\n\u003e toward using argument to signal their alliances and reduce the status of\n\u003e their opponents.\n\nI really appreciate your efforts to mediate in this dispute and I\nhonestly hope that my previous answer is useful as it is.\n\n\u003e I think it'd be very helpful if more 1MB advocates\n\u003e described what exactly would make them say \"OK, in this situation a block\n\u003e size increase is needed, we should do one quickly!\", and also if\n\u003e Gavin/Mike/Jeff described what hypothetical scenarios and/or test results\n\u003e would make them want to stick with 1MB blocks for now.\n\nJust replace 1MB with ANY size.\nBut, yes, please, when will you consider a size to be too dangerous\nfor centralization?\nWhy 20 GB would have been safe but 21 GB wouldn't have been (or the\nrespective maximums and respective +1)?\n\nNote that \"Never, 20GB was just a number closer to infinity than 1MB\nand I hoped that could had been voluntarily accepted by users. What I\nreally want is to completely remove this consensus rule forever.\" is a\nperfectly valid answer. It just means that I will agree with people\nthat think this way as explained in [1] (yes, not even after\nsuperluminal communication).\n\nAs an less relevant note, I feel extremely uncomfortable about being\nincluded in the \"1MB advocates\" group. As I've tried to explain\nseveral times, 1 is to me an arbitrary number like any other (at most,\nthe canonical arbitrary number), and so it is 1000000\n(MAX_BLOCK_SIZE). I rarely like being grouped or labelled, but maybe\nsomething more accurate like \"not-recklessly-change-consensus-rules\nadvocates\" would help.\nThere's nothing special about 1MB apart from being the current rule,\nso I don't think the number is that much relevant to the discussion.\nGrouping anyone that has raised any concern about rising the consensus\nblock size limit as \"the 1MBers\" is about as fair as grouping anyone\nthat has ever proposed a rise in the maximum size as \"the 20GBers\"\n(specially when there's people that belong to both groups\nsimultaneously, like Pieter Wuille who started this thread, and whose\nproposal we're supposed to be discussing).\n\n[1] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009947.html"}