{"type":"rich","version":"1.0","author_name":"npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","author_url":"https://nostr.ae/npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-07-10\n📝 Original message:Summary\n=========\n\nIn my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few\ncrucial ways. One success was that it synchronized the entire Bitcoin\ncommunity, helping to bring finality to the (endless) conversations of\nthat time, and get everyone back to work. However, I feel that the Dec\n7, 2015 roadmap is simply too old to serve this function any longer. We\nshould revise it: remove what has been accomplished, introduce new\ninnovations and approaches, and update deadlines and projections.\n\n\nWhy We Should Update the Roadmap\n=================================\n\nIn a P2P system like Bitcoin, we lack authoritative info-sources (for\nexample, a \"textbook\" or academic journal), and as a result\nconversations tend to have a problematic lack of progress. They do not\n\"accumulate\", as everyone must start over. Ironically, the scaling\nconversation _itself_ has a fatal O(n^2) scaling problem.\n\nThe roadmap helped solve these problems by being constant in size, and\nsubjecting itself to publication, endorsement, criticism, and so forth.\nDespite the (unavoidable) nuance and complexity of each individual\nopinion, it was at least globally known that X participants endorsed Y\nset of claims.\n\nUnfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite\nobsolete and replacing it is long overdue. For example, it highlights\nolder items (CSV, compact blocks, versionbits) as being _future_\nimprovements, and makes no mention of new high-likelihood improvements\n(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit\nfraud proofs). To read the old roadmap properly, one must already be a\ntechnical expert. For me, this defeats the entire point of having one in\nthe first place.\n\nA new roadmap would be worth your attention, even if you didn't sign it,\nbecause a refusal to sign would still be informative (and, therefore,\nhelpful)!\n\nSo, with that in mind, let me present a first draft. Obviously, I am\nstrongly open to edits and feedback, because I have no way of knowing\neveryone's opinions. I admit that I am partially campaigning for my\nDrivechain project, and also for this \"scalability\"/\"capacity\"\ndistinction...that's because I believe in both and think they are\nhelpful. But please feel free to suggest edits.\n\nI emphasized concrete numbers, and concrete dates.\n\nAnd I did NOT necessarily write it from my own point of view, I tried\nearnestly to capture a (useful) community view. So, let me know how I did.\n\n ==== Beginning of New (\"July 2017\") Roadmap Draft ====\n\nThis document updates the previous roadmap [1] of Dec 2015. The older\nstatement endorsed a belief that \"the community is ready to deliver on\nits shared vision that addresses the needs of the system while upholding\nits values\".\n\nThat belief has not changed, but the shared vision has certainly grown\nsharper over the last 18 months. Below is a list of technologies which\neither increase Bitcoin's maximum tps rate (\"capacity\"), or which make\nit easier to process a higher volume of transactions (\"scalability\").\n\nFirst, over the past 18 months, the technical community has completed a\nnumber of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables\nBitcoin to handle multiple soft fork upgrades at once. Compact Blocks\n(BIP 152) allows for much faster block propagation, as does the FIBRE\nNetwork [3]. Check Sequence Verify (BIP 112) allows trading partners to\nmutually update an active transaction without writing it to the\nblockchain (this helps to enable the Lightning Network).\n\nSecond, Segregated Witness (BIP 141), which reorganizes data in blocks\nto handle signatures separately, has been completed and awaits\nactivation (multiple BIPS). It is estimated to increase capacity by a\nfactor of 2.2. It also improves scalability in many ways. First, SW\nincludes a fee-policy which encourages users to minimize their impact on\nthe UTXO set. Second, SW achieves linear scaling of sighash operations,\nwhich prevents the network from crashing when large transactions are\nbroadcast. Third, SW provides an efficiency gain for everyone who is not\nverifying signatures, as these no longer need to be downloaded or\nstored. SegWit is an enabling technology for the Lightning Network,\nscript versioning (specifically Schnorr signatures), and has a number of\nbenefits which\nare unrelated to capacity [4].\n\nThird, the Lightning Network, which allows users to transact without\nbroadcasting to the network, is complete [5, 6] and awaits the\nactivation of SegWit. For those users who are able to make a single\non-chain transaction, it is estimated to increase both capacity and\nscalability by a factor of ~1000 (although these capacity increases will\nvary with usage patterns). LN also greatly improves transaction speed\nand transaction privacy.\n\nFourth, Transaction Compression [7], observes that Bitcoin transaction\nserialization is not optimized for storage or network communication. If\ntransactions were optimally compressed (as is possible today), this\nwould improve scalability, but not capacity, by roughly 20%, and in some\ncases over 30%.\n\nFifth, Schnorr Signature Aggregation, which shrinks transactions by\nallowing many transactions to have a single shared signature, has been\nimplemented [8] in draft form in libsecp256k1, and will likely be ready\nby Q4 of 2016. One analysis [9] suggests that signature aggregation\nwould result in storage and bandwidth savings of at least 25%, which\nwould therefore increase scalability and capacity by a factor of 1.33.\nThe relative savings are even greater for multisignature transactions.\n\nSixth, drivechain [10], which allows bitcoins to be temporarily\noffloaded to 'alternative' blockchain networks (\"sidechains\"), is\ncurrently under peer review and may be usable by end of 2017. Although\nit has no impact on scalability, it does allow users to opt-in to\ngreater capacity, by moving their BTC to a new network (although, they\nwill achieve less decentralization as a result). Individual drivechains\nmay have different security tradeoffs (for example, a greater reliance\non UTXO commitments, or MimbleWimble's shrinking block history) which\nmay give them individually greater scalability than mainchain Bitcoin.\n\nFinally, the capacity improvements outlined above may not be sufficient.\nIf so, it may be necessary to use a hard fork to increase the blocksize\n(and blockweight, sigops, etc) by a moderate amount. Such an increase\nshould take advantage of the existing research on hard forks, which is\nsubstantial [11]. Specifically, there is some consensus that Spoonnet\n[12] is the most attractive option for such a hardfork. There is\ncurrently no consensus on a hard fork date, but there is a rough\nconsensus that one would require at least 6 months to coordinate\neffectively, which would place it in the year 2018 at earliest.\n\nThe above are only a small sample of current scaling technologies. And\neven an exhaustive list of scaling technologies, would itself only be a\nsmall sample of total Bitcoin innovation (which is proceeding at\nbreakneck speed).\n\nSigned,\n\u003cNames Here\u003e\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html\n[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/\n[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/\n[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/\n[5]\nhttp://lightning.community/release/software/lnd/lightning/2017/05/03/litening/\n[6] https://github.com/ACINQ/eclair\n[7] https://people.xiph.org/~greg/compacted_txn.txt\n[8]\nhttps://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594\n[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/\n[10] http://www.drivechain.info/\n[11] https://bitcoinhardforkresearch.github.io/\n[12]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html\n\n ==== End of Roadmap Draft ====\n\nIn short, please let me know:\n\n1. If you agree that it would be helpful if the roadmap were updated.\n2. To what extent, if any, you like this draft.\n3. Edits you would make (specifically, I wonder about Drivechain\nthoughts and Hard Fork thoughts, particularly how to phrase the Hard\nFork date).\n\nGoogle Doc (if you're into that kind of thing):\nhttps://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing\n\nCheers,\nPaul\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170710/60d2fe7d/attachment.sig\u003e"}