{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-16\n📝 Original message:All,\n\nFollowing the guiding WP principle of Assume Good Faith, I've been trying\nto boil down the essence of the message following Scaling Bitcoin.  There\nare key bitcoin issues that remain outstanding and pressing, that are*\northogonal to LN \u0026 SW*.\n\nI create multiple proposals and try multiple angles because of a few,\nnotable systemic economic and analysis issues - multiple tries at solving\nthe same problems.  Why do I do what I do -- Why not try to reboot... just\nlist those problems?\n\nDefinitions:\n\nFE - \"Fee Event\", the condition where main chain MSG_BLOCK is 95+% to hard\nlimit for 7 or more days in row, \"blocks generally full\"   This can also be\ninduced by a miner squeeze (collective soft limit reduction).\n\n\nService - a view of bitcoin as a decentralized, faceless, multi-celled,\namorphous automaton cloud, that provides services in exchange for payment\n\nUsers - total [current | future] set of economic actors that pay money to\nthe Service, and receive value (figuratively or literally) in return\n\nBlock Size - This is short hand for MAX_BLOCK_SIZE, the hard limit that\nrequires, today, a hard fork to increase (excl. extension blocks etc.)\n\n\nGuiding Principle:\n\nKeep the Service alive, secure, decentralized, and censorship resistant for\nas many Users as possible.\n\n\nObservations on block size (shorthand for MAX_BLOCK_SIZE as noted above):\n\nThis is economically modeled as a supply limited resource over time.  On\naverage, 1M capacity is available every 10 minutes, with variance.\n\n\nObservations on Users, block size and modern bidding process:\n\nA supermajority of hashpower currently evaluates for block inclusion based,\nfirst-pass, on tx-fee/KB.  Good.\n\nThe Service is therefore responsive to the free market and some classes of\nDoS.  Good.\n\nRecent mempool changes float relay fee, making the Service more responsive\nto fast moving markets and DoS's.  Good progress.\n\n\nService provided to Users can be modeled at the bandwidth resource level as\nbidding for position in a virtual priority queue, where up-to-1M bursts are\ncleared every 10 min (on avg etc.).  Not a perfectly fixed supply,\ndefinitionally, but constrained within a fixed range.\n\n\nObservations on the state of today's fee market:\n\nOn average, blocks are not full.  Economically, this means that fees trend\ntowards zero, due to theoretically unlimited supply at \u003c1M levels.\n\nOf course, fees are not zero.  The network relay anti-flood limits serve as\nan average lower limit for most transactions (excl direct-to-miner).\nWallet software also introduces fee variance in interesting ways.  All this\nfee activity is range-bound on the low end.\n\nLet the current set of Users + transaction fee market behavior be TFM\n(today's fee market).\nLet the post-Fee-Event set of Users + transaction fee market behavior be\nFFM (future fee market).\n\n*Key observation:   A Bitcoin Fee Event (see def. at top) is an Economic\nChange Event.*\n\nAn Economic Change Event is a period of market chaos, where large changes\nto prices and sets of economic actors occurs over a short time period.\n\nA Fee Event is a notable Economic Change Event, where a realistic\nprojection forsees higher fee/KB on average, pricing some economic actors\n(bitcoin projects and businesses) out of the system.\n\n*It is a major change to how current Users experience and pay for the\nService*, state change from TFM to FFM.\n\nThe game theory bidding behavior is different for a mostly-empty resource\nversus a usually-full resource.  Prices are different.  Profitable business\nmodels are different.  Users (the set of economic actors on the network)\nare different.\n\n\nObservation:  Contentious hard fork is an Economic Change Event.\n\nSimilarly, a fork that partitions economic actors for an extended period or\npermanently is also an Economic Change Event, shuffling prices and economic\nactors as the Service dynamically readjusts on both sides of the partition,\nand Users-A and Users-B populations change their behavior.\n\n\n\nShort-Term Problem #1:  No-action on block size increase leads to an\nEconomic Change Event.\n\n\nFailure to increase block size is not obviously-conservative, it is a\nconscious choice, electing for one economic state and set of actors and\nprices over another.  Choosing FFM over TFM.\n\n*It is rational to reason that maintaining TFM is more conservative* than\nenduring an Economic Change Event from TFM to FFM.\n\n*It is rational to reason that maintaining similar prices and economic\nactors is less disruptive.*\n\nFailure to increase block size will lead to a Fee Event sooner rather than\nlater.\n\nFailure to plan ahead for a Fee Event will lead to greater market chaos and\nUser pain.\n\n\nShort-Term Problem #2:  Some Developers wish to accelerate the Fee Event,\nand a veto can accomplish that.\n\nIn the current developer dynamics, 1-2 key developers can and very likely\nwould veto any block size increase.\n\nThus a veto (e.g. no-action) can lead to a Fee Event, which leads to\npricing actors out of the system.\n\nA block size veto wields outsize economic power, because it can accelerate\nECE.\n\n*This is an extreme moral hazard:  A few Bitcoin Core committers can veto\nincrease and thereby reshape bitcoin economics, price some businesses out\nof the system.  It is less of a moral hazard to keep the current economics\n[by raising block size] and not exercise such power.*\n\n\nShort-Term Problem #3:  User communication and preparation\n\nThe current trajectory of no-block-size-increase can lead to short time\nmarket chaos, actor chaos, businesses no longer viable.\n\nIn a $6.6B economy, it is criminal to let the Service undergo an ECE\nwithout warning users loudly, months in advance:  \"Dear users, ECE has\naccelerated potential due to developers preferring a transition from TFM to\nFFM.\"\n\nAs stated, *it is a conscious choice to change bitcoin economics and User\nexperience* if block size is not advanced with a healthy buffer above\nactual average traffic levels.\n\n*Raising block size today, at TFM, produces a smaller fee market delta.*\n\nFurther, wallet software User experience is very, very poor in a\nhyper-competitive fee market.   (This can and will be improved; that's just\nthe state of things today)\n\n\nShort-Term Problem #4:  User/Dev disconnect:   Large mass of users wishes\nto push Fee Event into future\n\nAlmost all bitcoin businesses, exchanges and miners have stated they want a\nblock size increase.  See the many media articles, BIP 101 letter, and wiki\ne.g.\nhttps://en.bitcoin.it/wiki/Block_size_limit_controversy#Entities_positions\n\nThe current apparent-veto on block size increase runs contra to the desires\nof many Users.  (note language: \"many\", not claiming \"all\")\n\n*It is a valid and rational economic choice to subsidize the system with\nlower fees in the beginning*.  Many miners, for example, openly state they\nprefer long term system growth over maximizing tiny amounts of current day\nincome.\n\nVetoing a block size increase has the effect of eliminating that economic\nchoice as an option.\n\n\nIt is difficult to measure Users; projecting beyond \"businesses and miners\"\nis near impossible.\n\nWithout exaggeration, I have never seen this much disconnect between user\nwishes and dev outcomes in 20+ years of open source.\n\n\nShort-Term Problem #5:  Higher Service prices can negatively impact system\nsecurity\n\nBitcoin depends on a virtuous cycle of users boosting and maintaining\nbitcoin's network effect, incentivizing miners, increasing security.\n\nHigher prices that reduce bitcoin's user count and network effect can have\nthe opposite impact.\n\n(Obviously this is a dynamic system, users and miners react to higher\nprices... including actions that then reduce the price)\n\nShort-Term Problem #6:  Post-Fee-Event market reboot problem + general lack\nof planning\n\nGame it out:   Blocks are now full (FFM).  Block size kept at 1M.\n\nHow full is too full - who and what dictates when 1M should be increased?\n\nThe same question remains, yet now economic governance issues are\ncompounded:  In FFM, the fees are very tightly bound to the upper bound of\nthe block size.  In TFM, fees are much less sensitive to the upper bound of\nblock size.\n\n\nChanging block size, when blocks are full, has a more dramatic effect on\nthe market - suddenly new supply is magically brought online, and a minor\nEconomic Change Event occurs.\n\nMore generally, the post-Fee-Event next step has not been agreed upon.  Is\nit flexcap?  This key \"step #2\" is just barely at whiteboard stage.\n\n\nShort-Term Problem #7:   Fee Event timing is unpredictable.\n\nAs block size free space gets tighter - that is the trend - and block size\nremains at 1M, Users are ever more likely to hit an Economic Change Event.\nIt could happen in the next 2-6 months.\n\nToday, Users and wallets are not prepared.\n\nIt is also understandably a very touchy subject to say \"your business or\nuse case might get priced out of bitcoin\"\n\n\nBut it is even worse to let worse let Users run into a Fee Event without\ninforming the market that the block size will remain at 1M.\n\nMarkets function best with maximum knowledge - when they are informed well\nin advance of market shifting news and events, giving economic actors time\nto prepare.\n\n\nShort-Term Problem #8:   Very little testing, data, effort put into\nblocks-mostly-full economics\n\n*We only know for certain that blocks-mostly-not-full works.*  We do not\nknow that changing to blocks-mostly-full works.\n\nChanging to a new economic system includes boatloads of risk.\n\nVery little data has been forthcoming from any party on what FFM might look\nlike, following a Fee Event.\n\n\nObservation:   In the long run, it is assumed we need a \"healthy fee market\"\n\nYes, absolutely.  In the long run, bitcoin was intended to be supported by\ntransaction fees and not the minting of new supply, and the design of the\nsystem is to slowly wean Users off new supply and onto transaction fees for\nsupporting the Service.\n\nWhile agreeing with the goal, it must be acknowledge that this is a vague\nand untested goal with many open economic questions -- more of a hope,\nreally.\n\nIt is more conservative to preserve current economics than to change to a\nnew system with new economics and no notion of what-comes-next (flexcap?)\nin terms of system security, healthy sustainable market levels, and impact\nof changes during and following an ECE.\n\n\n\nCore recommendations:\n\n1) \"Short term bump\"  Block size increase to maintain buffer.  I've no\nspecial BIP preference.\n\nThis avoids moral hazard and avoids a major Economic Change Event, as well\nmany other risks.\n\n\n2) If block size stays at 1M, the Bitcoin Core developer team should sign a\ncollective note stating their desire to transition to a new economic\npolicy, that of \"healthy fee market\" and strongly urge users to examine\ntheir fee policies, wallet software, transaction volumes and other possible\nUser impacting outcomes.\n\n\n3) Even if can is kicked down the road, Fee Event will come eventually.\nDirect research, testing and simulations into the economics and user impact\nside of the equation.  Research and experiment with pay-for-burst (pay to\nfuture miner), flexcap and other solutions ASAP.\n\n\nThe worst possible outcome is letting the ecosystem randomly drift into the\nfirst Fee Event without openly stating the new economic policy choices and\nconsequences.\n\nThe simple fact is *inaction* on this supply-limited resource, block size,\nwill change bitcoin to a new economic shape and with different economic\nactors, selecting some and not others.\n\nIt is better to kick the can and gather crucial field data, because\nnext-step (FFM) is very much not fleshed out.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/024095fb/attachment-0001.html\u003e"}