{"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-12-07\n📝 Original message:The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating\nproposals were presented. I think this would be a good time to share my\nview of the near term arc for capacity increases in the Bitcoin system. I\nbelieve we’re in a fantastic place right now and that the community\nis ready to deliver on a clear forward path with a shared vision that\naddresses the needs of the system while upholding its values.\n\nI think it’s important to first clearly express some of the relevant\nprinciples that I think should guide the ongoing development of the\nBitcoin system.\n\nBitcoin is P2P electronic cash that is valuable over legacy systems\nbecause of the monetary autonomy it brings to its users through\ndecentralization. Bitcoin seeks to address the root problem with\nconventional currency: all the trust that's required to make it work--\n\n-- Not that justified trust is a bad thing, but trust makes systems\nbrittle, opaque, and costly to operate. Trust failures result in systemic\ncollapses, trust curation creates inequality and monopoly lock-in, and\nnaturally arising trust choke-points can be abused to deny access to\ndue process. Through the use of cryptographic proof and decentralized\nnetworks Bitcoin minimizes and replaces these trust costs.\n\nWith the available technology, there are fundamental trade-offs between\nscale and decentralization. If the system is too costly people will be\nforced to trust third parties rather than independently enforcing the\nsystem's rules. If the Bitcoin blockchain’s resource usage, relative\nto the available technology, is too great, Bitcoin loses its competitive\nadvantages compared to legacy systems because validation will be too\ncostly (pricing out many users), forcing trust back into the system.\nIf capacity is too low and our methods of transacting too inefficient,\naccess to the chain for dispute resolution will be too costly, again\npushing trust back into the system.\n\nSince Bitcoin is an electronic cash, it _isn't_ a generic database;\nthe demand for cheap highly-replicated perpetual storage is unbounded,\nand Bitcoin cannot and will not satisfy that demand for non-ecash\n(non-Bitcoin) usage, and there is no shame in that. Fortunately, Bitcoin\ncan interoperate with other systems that address other applications,\nand--with luck and hard work--the Bitcoin system can and will satisfy\nthe world's demand for electronic cash.\n\nFortunately, a lot of great technology is in the works that make\nnavigating the trade-offs easier.\n\nFirst up: after several years in the making Bitcoin Core has recently\nmerged libsecp256k1, which results in a huge increase in signature\nvalidation performance. Combined with other recent work we're now getting\nConnectTip performance 7x higher in 0.12 than in prior versions. This\nhas been a long time coming, and without its anticipation and earlier\nwork such as headers-first I probably would have been arguing for a\nblock size decrease last year.  This improvement in the state of the\nart for widely available production Bitcoin software sets a stage for\nsome capacity increases while still catching up on our decentralization\ndeficit. This shifts the bottlenecks off of CPU and more strongly onto\npropagation latency and bandwidth.\n\nVersionbits (BIP9) is approaching maturity and will allow the Bitcoin\nnetwork to have multiple in-flight soft-forks. Up until now we’ve had to\ncompletely serialize soft-fork work, and also had no real way to handle\na soft-fork that was merged in core but rejected by the network. All\nthat is solved in BIP9, which should allow us to pick up the pace of\nimprovements in the network. It looks like versionbits will be ready\nfor use in the next soft-fork performed on the network.\n\nThe next thing is that, at Scaling Bitcoin Hong Kong, Pieter Wuille\npresented on bringing Segregated Witness to Bitcoin. What is proposed\nis a _soft-fork_ that increases Bitcoin's scalability and capacity by\nreorganizing data in blocks to handle the signatures separately, and in\ndoing so takes them outside the scope of the current blocksize limit.\n\nThe particular proposal amounts to a 4MB blocksize increase at worst. The\nseparation allows new security models, such as skipping downloading data\nyou're not going to check and improved performance for lite clients\n(especially ones with high privacy). The proposal also includes fraud\nproofs which make violations of the Bitcoin system provable with a compact\nproof. This completes the vision of \"alerts\" described in the \"Simplified\nPayment Verification\" section of the Bitcoin whitepaper, and would make it\npossible for lite clients to enforce all the rules of the system (under\na new strong assumption that they're not partitioned from someone who\nwould generate the proofs). The design has numerous other features like\nmaking further enhancements safer and eliminating signature malleability\nproblems. If widely used this proposal gives a 2x capacity increase\n(more if multisig is widely used), but most importantly it makes that\nadditional capacity--and future capacity beyond it--safer by increasing\nefficiency and allowing more trade-offs (in particular, you can use much\nless bandwidth in exchange for a strong non-partitioning assumption).\n\nThere is a working implementation (though it doesn't yet have the fraud\nproofs) at https://github.com/sipa/bitcoin/commits/segwit\n\n(Pieter's talk is at:  transcript:\nhttp://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/\nslides:\nhttps://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/\nVideo: https://www.youtube.com/watch?v=fst1IK_mrng#t=36m )\n\nI had good success deploying an earlier (hard-fork) version of segwit\nin the Elements Alpha sidechain; the soft-fork segwit now proposed\nis a second-generation design. And I think it's quite reasonable to\nget this deployed in a relatively short time frame. The segwit design\ncalls for a future bitcoinj compatible hardfork to further increase its\nefficiency--but it's not necessary to reap most of the benefits,and that\nmeans it can happen on its own schedule and in a non-contentious manner.\n\nGoing beyond segwit, there has been some considerable activity brewing\naround more efficient block relay.  There is a collection of proposals,\nsome stemming from a p2pool-inspired informal sketch of mine and some\nindependently invented, called \"weak blocks\", \"thin blocks\" or \"soft\nblocks\".  These proposals build on top of efficient relay techniques\n(like the relay network protocol or IBLT) and move virtually all the\ntransmission time of a block to before the block is found, eliminating\nsize from the orphan race calculation. We already desperately need this\nat the current block sizes. These have not yet been implemented, but\nfortunately the path appears clear. I've seen at least one more or less\ncomplete specification, and I expect to see things running using this in a\nfew months. This tool will remove propagation latency from being a problem\nin the absence of strategic behavior by miners.  Better understanding\ntheir behavior when miners behave strategically is an open question.\n\nConcurrently, there is a lot of activity ongoing related to\n“non-bandwidth” scaling mechanisms. Non-bandwidth scaling mechanisms\nare tools like transaction cut-through and bidirectional payment channels\nwhich increase Bitcoin’s capacity and speed using clever smart contracts\nrather than increased bandwidth. Critically, these approaches strike right\nat the heart of the capacity vs autotomy trade-off, and may allow us to\nachieve very high capacity and very high decentralization. CLTV (BIP65),\ndeployed a month ago and now active on the network, is very useful for\nthese techniques (essential for making hold-up refunds work); CSV (BIP68\n/ BIP112) is in the pipeline for merge in core and making good progress\n(and will likely be ready ahead of segwit). Further Bitcoin protocol\nimprovements for non-bandwidth scaling are in the works: Many of these\nproposals really want anti-malleability fixes (which would be provided\nby segwit), and there are checksig flag improvements already tendered and\nmore being worked on, which would be much easier to deploy with segwit. I\nexpect that within six months we could have considerably more features\nready for deployment to enable these techniques. Even without them I\nbelieve we’ll be in an acceptable position with respect to capacity\nin the near term, but it’s important to enable them for the future.\n\n(http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning\nis a relevant talk for some of the wanted network features for Lightning,\na bidirectional payment channel proposal which many parties are working\non right now; other non-bandwidth improvements discussed in the past\ninclude transaction cut-through, which I consider a must-read for the\nbasic intuition about how transaction capacity can be greater than\nblockchain capacity: https://bitcointalk.org/index.php?topic=281848.0 ,\nthough there are many others.)\n\nFurther out, there are several proposals related to flex caps or\nincentive-aligned dynamic block size controls based on allowing miners\nto produce larger blocks at some cost. These proposals help preserve\nthe alignment of incentives between miners and general node operators,\nand prevent defection between the miners from undermining the fee\nmarket behavior that will eventually fund security. I think that right\nnow capacity is high enough and the needed capacity is low enough that\nwe don't immediately need these proposals, but they will be critically\nimportant long term. I'm planning to help out and drive towards a more\nconcrete direction out of these proposals in the following months.\n\n(Relevant talks include\nhttp://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/\n)\n\nFinally--at some point the capacity increases from the above may not\nbe enough.  Delivery on relay improvements, segwit fraud proofs, dynamic\nblock size controls, and other advances in technology will reduce the risk\nand therefore controversy around moderate block size increase proposals\n(such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will\nbe able to move forward with these increases when improvements and\nunderstanding render their risks widely acceptable relative to the\nrisks of not deploying them. In Bitcoin Core we should keep patches\nready to implement them as the need and the will arises, to keep the\nbasic software engineering from being the limiting factor.\n\nOur recent and current progress has well positioned the Bitcoin ecosystem\nto handle its current capacity needs. I think the above sets out some\nclear achievable milestones to continue to advance the art in Bitcoin\ncapacity while putting us in a good position for further improvement and\nevolution.\n\nTL;DR:  I propose we work immediately towards the segwit 4MB block\nsoft-fork which increases capacity and scalability, and recent speedups\nand incoming relay improvements make segwit a reasonable risk. BIP9\nand segwit will also make further improvements easier and faster to\ndeploy. We’ll continue to set the stage for non-bandwidth-increase-based\nscaling, while building additional tools that would make bandwidth\nincreases safer long term. Further work will prepare Bitcoin for further\nincreases, which will become possible when justified, while also providing\nthe groundwork to make them justifiable.\n\nThanks for your time,"}