{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-06\n📝 Original message:On Wed, May 6, 2015 at 10:12 PM, Matt Corallo \u003cbitcoin-list at bluematt.me\u003e\nwrote: \u003e Recently there has been a flurry of posts by Gavin at \u003e\nhttp://gavinandresen.svbtle.com/ which advocate strongly for increasing \u003e\nthe maximum block size. However, there hasnt been any discussion on this \u003e\nmailing list in several years as far as I can tell.\n\nThanks Matt; I was actually really confused by this sudden push with\nnot a word here or on Github--so much so that I responded on Reddit to\npeople pointing to commits in Gavin's personal repository saying they\nwere reading too much into it.\n\nSo please forgive me for the more than typical disorganization in this\nmessage; I've been caught a bit flatfooted on this and I'm trying to\ncatch up. I'm juggling a fair amount of sudden pressure in my mailbox,\nand trying to navigate complex discussions in about eight different\nforums concurrently.\n\nThere have been about a kazillion pages of discussion elsewhere\n(e.g. public IRC and Bitcointalk; private discussions in the past),\nnot all of which is well known, and I can't hope to summarize even a\ntiny fraction of it in a single message-- but that's no reason to not\nstart on it.\n\n\u003e Block size is a question to which there is no answer, but which \u003e\ncertainly has a LOT of technical tradeoffs to consider.\n\nThere are several orthogonal angles from which block size is a concern\n(both increases and non-increases). Most of them have subtle implications\nand each are worth its own research paper or six, so it can be difficult\nto only touch them slightly without creating a gish gallop that is hard\nto respond to.\n\nWe're talking about tuning one of the fundamental scarcities of the\nBitcoin Economy and cryptosystem--leaving the comfort of \"rule by\nmath\" and venturing into the space of political decisions; elsewhere\nyou'd expect to see really in-depth neutral analysis of the risks and\ntradeoffs, technically and economically.  And make no mistake: there\nare real tradeoffs here, though we don't know their exact contours.\n\nFundamentally this question exposes ideological differences between people\ninterested in Bitcoin.  Is Bitcoin more of a digital gold or is it more\nof a competitor to Square?  Is Bitcoin something that should improve\npersonal and commercial autonomy from central banks?  From commercial\nbanks? Or from just the existing status-quo commercial banks?   What are\npeople's fundamental rights with Bitcoin?  Do participants have a\nright to mine? How much control should third parties have over their\ntransactions?  How much security must be provided? Is there a deadline\nfor world domination or bust?  Is Bitcoin only for the developed world?\nMust it be totally limited by the most impoverished parts of the world?\n\nBitcoin exists at the intersection of many somewhat overlapping belief\nsystems--and people of many views can find that Bitcoin meets their\nneeds even when they don't completely agree politically.  When Bitcoin\nis changed fundamentally, via a hard fork, to have different properties,\nthe change can create winners or losers (if nothing else, then in terms\nof the kind of ideology supported by it).\n\nThere are non-trivial number of people who hold extremes on any of\nthese general belief patterns; Even among the core developers there is\nnot a consensus on Bitcoin's optimal role in society and the commercial\nmarketplace.\n\nTo make it clear how broad the views go, even without getting into\nmonetary policy... some people even argue that Bitcoin should act\nas censor-resistant storage system for outlawed content; -- I think\nthis view is unsound, not achievable with the technology, and largely\nincompatible with Bitcoin's use as a money (because it potentially\ncreates an externalized legal/harassment liability for node operators);\nbut these are my personal value judgments; the view is earnestly held\nby more than a few; and that's a group that certainly wants the largest\npossible blocksizes (though even then that won't be enough).\n\nThe subject is complicated even more purely on the technical side\nby the fact that Bitcoin has a layered security model which is not\ncompletely defined or understood: Bitcoin is secure if a majority of\nhashrate is \"honest\" (where \"honesty\" is a technical term which means\n\"follows the right rules\" without fail, even at a loss), but why might\nit be honest? That sends us into complex economic and social arguments,\nand the security thresholds start becoming worse when we assume some\nminers are economically rational instead of \"honest\".\n\n\u003e increase in the near future. Long-term incentive compatibility requires\n\u003e that there be some fee pressure, and that blocks be relatively \u003e\nconsistently full or very nearly full. What we see today are\n\nTo elaborate, in my view there is a at least a two fold concern on this\nparticular (\"Long term Mining incentives\") front:\n\nOne is that the long-held argument is that security of the Bitcoin system\nin the long term depends on fee income funding autonomous, anonymous,\ndecentralized miners profitably applying enough hash-power to make\nreorganizations infeasible.\n\nFor fees to achieve this purpose, there seemingly must be an effective\nscarcity of capacity.  The fact that verifying and transmitting\ntransactions has a cost isn't enough, because all the funds go to pay\nthat cost and none to the POW \"artificial\" cost; e.g., if verification\ncosts 1 then the market price for fees should converge to 1, and POW\ncost will converge towards zero because they adapt to whatever is\nbeing applied. Moreover, the transmission and verification costs can\nbe perfectly amortized by using large centralized pools (and efficient\ndifferential block transmission like the \"O(1)\" idea) as you can verify\none time instead of N times, so to the extent that verification/bandwidth\nis a non-negligible cost to miners at all, it's a strong pressure to\ncentralize.  You can understand this intuitively: think for example of\ncarbon credit cap-and-trade: the trade part doesn't work without an\nactual cap; if everyone was born with a 1000 petaton carbon balance,\nthe market price for credits would be zero and the program couldn't hope\nto share behavior. In the case of mining, we're trying to optimize the\nsocial good of POW security. (But the analogy applies in other ways too:\nincreases to the chain side are largely an externality; miners enjoy the\nbenefits, everyone else takes the costs--either in reduced security or\nhigher node operating else.)\n\nThis area has been subject to a small amount of academic research\n(e.g. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519). But\nthere is still much that is unclear.\n\nThe second is that when subsidy has fallen well below fees, the incentive\nto move the blockchain forward goes away.  An optimal rational miner\nwould be best off forking off the current best block in order to capture\nits fees, rather than moving the blockchain forward, until they hit\nthe maximum. That's where the \"backlog\" comment comes from, since when\nthere is a sufficient backlog it's better to go forward.  I'm not aware\nof specific research into this subquestion; it's somewhat fuzzy because\nof uncertainty about the security model. If we try to say that Bitcoin\nshould work even in the face of most miners being profit-maximizing\ninstead of altruistically-honest, we must assume the chain will not\nmore forward so long as a block isn't full.  In reality there is more\naltruism than zero; there are public pressures; there is laziness, etc.\n\nOne potential argument is that maybe miners would be _regulated_ to\nbehave correctly. But this would require undermining the openness of the\nsystem--where anyone can mine anonymously--in order to enforce behavior,\nand that same enforcement mechanism would leave a political level to\nimpose additional rules that violate the extra properties of the system.\n\nSo far the mining ecosystem has become incredibly centralized over time.\nI believe I am the only remaining committer who mines, and only a few\nof the regular contributors to Bitcoin Core do. Many participants\nhave never mined or only did back in 2010/2011... we've basically\nignored the mining ecosystem, and this has had devastating effects,\ncausing a latent undermining of the security model: hacking a dozen or\nso computers--operated under totally unknown and probably not strong\nsecurity policies--could compromise the network at least at the tip...\nRightfully we should be regarding this an an emergency, and probably\nshould have been have since 2011.  This doesn't bode well for our ability\nto respond if a larger blocksize goes poorly. In kicking the can with\nthe trivial change to just bump the size, are we making an implicit\ndecision to go down a path that has a conclusion we don't want?\n\n(There are also shorter term mining incentives concerns; which Peter\nTodd has written more about, that I'll omit for now)\n\n\u003e pretending these systems scale. Thus, instead of working on technologies\n\u003e which bring Bitcoin's trustlessness to systems which scale beyond a\n\nI made a few relevant points back in 2011\n(https://en.bitcoin.it/w/index.php?title=Scalability\u0026action=historysubmit\u0026diff=14273\u0026oldid=14112)\nafter Dan Kaminsky argued that Bitcoin's decentralization was pretext:\nthat it was patently centralized since scaling directly in the network\nwould undermine decentralization, that the Bitcoin network necessarily\nmakes particular tradeoffs which prevent it from concurrently being all\nthings to all people.  But tools like the Lightning network proposal could\nwell allow us to hit a greater spectrum of demands at once--including\nsecure zero-confirmation (something that larger blocksizes reduce if\nanything), which is important for many applications.  With the right\ntechnology I believe we can have our cake and eat it too, but there needs\nto be a reason to build it; the security and decentralization level of\nBitcoin imposes a _hard_ upper limit on anything that can be based on it.\n\nAnother key point here is that the small bumps in blocksize which\nwouldn't clearly knock the system into a largely centralized mode--small\nconstants--are small enough that they don't quantitatively change the\noperation of the system; they don't open up new applications that aren't\npossible today. Deathandtaxes on the forum argued that Bitcoin needs\na several hundred megabyte blocksize to directly meet the worldwide\ntransaction needs _without retail_... Why without retail? Retail needs\nnear instant soft security, which cannot be achieved directly with a\nglobal decentralized blockchain.\n\nI don't think 1MB is magic; it always exists relative to widely-deployed\ntechnology, sociology, and economics. But these factors aren't a simple\nfunction; the procedure I'd prefer would be something like this: if there\nis a standing backlog, we-the-community of users look to indicators to\ngauge if the network is losing decentralization and then double the\nhard limit with proper controls to allow smooth adjustment without\nfees going to zero (see the past proposals for automatic block size\ncontrols that let miners increase up to a hard maximum over the median\nif they mine at quadratically harder difficulty), and we don't increase\nif it appears it would be at a substantial increase in centralization\nrisk. Hardfork changes should only be made if they're almost completely\nuncontroversial--where virtually everyone can look at the available data\nand say \"yea, that isn't undermining my property rights or future use\nof Bitcoin; it's no big deal\".  Unfortunately, every indicator I can\nthink of except fee totals has been going in the wrong direction almost\nmonotonically along with the blockchain size increase since 2012 when\nwe started hitting full blocks and responded by increasing the default\nsoft target.  This is frustrating; from a clean slate analysis of network\nhealth I think my conclusion would be to _decrease_ the limit below the\ncurrent 300k/txn/day level.\n\nThis is obviously not acceptable, so instead many people--myself\nincluded--have been working feverishly hard behind the scenes on Bitcoin\nCore to increase the scalability.  This work isn't small-potatoes\nboring software engineering stuff; I mean even my personal contributions\ninclude things like inventing a wholly new generic algebraic optimization\napplicable to all EC signature schemes that increases performance by 4%,\nand that is before getting into the R\u0026D stuff that hasn't really borne\nfruit yet, like fraud proofs.  Today Bitcoin Core is easily \u003e100 times\nfaster to synchronize and relay than when I first got involved on the\nsame hardware, but these improvements have been swallowed by the growth.\nThe ironic thing is that our frantic efforts to keep ahead and not\nlose decentralization have both not been enough (by the best measures,\nfull node usage is the lowest its been since 2011 even though the user\nbase is huge now) and yet also so much that people could seriously talk\nabout increasing the block size to something gigantic like 20MB. This\nsounds less reasonable when you realize that even at 1MB we'd likely\nhave a smoking hole in the ground if not for existing enormous efforts\nto make scaling not come at a loss of decentralization.\n\n\nI'm curious as to what discussions people have seen; e.g., are people\neven here aware of these concerns? Are you aware of things like the\nhashcash mediated dynamic blocksize limiting?  About proposals like\nlightning network (instant transactions and massive scale, in exchange\nfor some short term DOS risk if a counterparty opts out)?   Do people\n(other than Mike Hearn; I guess) think a future where everyone depends\non a small number of \"Google scale\" node operations for the system is\nactually okay? (I think not, and if so we're never going to agree--but\nit can be helpful to understand when a disagreement is ideological)."}