{"type":"rich","version":"1.0","author_name":"npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03","author_url":"https://nostr.ae/npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-07-11\n📝 Original message:Concept ACK.\n\nI think you are overstating the readiness of drivechains though. I think\nthe optimistic estimate for drivechains to be ready for bitcoin core is a\nyear out from today. More likely the date should be early 2018. Still a lot\nof work to be done! :-)\n\nAlso I don't know if I would put a hard fork suggestion in the scaling map.\nIf drivechains are successful they should be viewed as the way we scale --\nnot hard forking the protocol. Do you still have capacity concerns if\ndrivechains are successful?\n\n-Chris\n\nOn Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e Summary\n\u003e =========\n\u003e\n\u003e In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few\n\u003e crucial ways. One success was that it synchronized the entire Bitcoin\n\u003e community, helping to bring finality to the (endless) conversations of\n\u003e that time, and get everyone back to work. However, I feel that the Dec\n\u003e 7, 2015 roadmap is simply too old to serve this function any longer. We\n\u003e should revise it: remove what has been accomplished, introduce new\n\u003e innovations and approaches, and update deadlines and projections.\n\u003e\n\u003e\n\u003e Why We Should Update the Roadmap\n\u003e =================================\n\u003e\n\u003e In a P2P system like Bitcoin, we lack authoritative info-sources (for\n\u003e example, a \"textbook\" or academic journal), and as a result\n\u003e conversations tend to have a problematic lack of progress. They do not\n\u003e \"accumulate\", as everyone must start over. Ironically, the scaling\n\u003e conversation _itself_ has a fatal O(n^2) scaling problem.\n\u003e\n\u003e The roadmap helped solve these problems by being constant in size, and\n\u003e subjecting itself to publication, endorsement, criticism, and so forth.\n\u003e Despite the (unavoidable) nuance and complexity of each individual\n\u003e opinion, it was at least globally known that X participants endorsed Y\n\u003e set of claims.\n\u003e\n\u003e Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite\n\u003e obsolete and replacing it is long overdue. For example, it highlights\n\u003e older items (CSV, compact blocks, versionbits) as being _future_\n\u003e improvements, and makes no mention of new high-likelihood improvements\n\u003e (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit\n\u003e fraud proofs). To read the old roadmap properly, one must already be a\n\u003e technical expert. For me, this defeats the entire point of having one in\n\u003e the first place.\n\u003e\n\u003e A new roadmap would be worth your attention, even if you didn't sign it,\n\u003e because a refusal to sign would still be informative (and, therefore,\n\u003e helpful)!\n\u003e\n\u003e So, with that in mind, let me present a first draft. Obviously, I am\n\u003e strongly open to edits and feedback, because I have no way of knowing\n\u003e everyone's opinions. I admit that I am partially campaigning for my\n\u003e Drivechain project, and also for this \"scalability\"/\"capacity\"\n\u003e distinction...that's because I believe in both and think they are\n\u003e helpful. But please feel free to suggest edits.\n\u003e\n\u003e I emphasized concrete numbers, and concrete dates.\n\u003e\n\u003e And I did NOT necessarily write it from my own point of view, I tried\n\u003e earnestly to capture a (useful) community view. So, let me know how I did.\n\u003e\n\u003e  ==== Beginning of New (\"July 2017\") Roadmap Draft ====\n\u003e\n\u003e This document updates the previous roadmap [1] of Dec 2015. The older\n\u003e statement endorsed a belief that \"the community is ready to deliver on\n\u003e its shared vision that addresses the needs of the system while upholding\n\u003e its values\".\n\u003e\n\u003e That belief has not changed, but the shared vision has certainly grown\n\u003e sharper over the last 18 months. Below is a list of technologies which\n\u003e either increase Bitcoin's maximum tps rate (\"capacity\"), or which make\n\u003e it easier to process a higher volume of transactions (\"scalability\").\n\u003e\n\u003e First, over the past 18 months, the technical community has completed a\n\u003e number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables\n\u003e Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks\n\u003e (BIP 152) allows for much faster block propagation, as does the FIBRE\n\u003e Network [3]. Check Sequence Verify (BIP 112) allows trading partners to\n\u003e mutually update an active transaction without writing it to the\n\u003e blockchain (this helps to enable the Lightning Network).\n\u003e\n\u003e Second, Segregated Witness (BIP 141), which reorganizes data in blocks\n\u003e to handle signatures separately, has been completed and awaits\n\u003e activation (multiple BIPS). It is estimated to increase capacity by a\n\u003e factor of 2.2. It also improves scalability in many ways. First, SW\n\u003e includes a fee-policy which encourages users to minimize their impact on\n\u003e the UTXO set. Second, SW achieves linear scaling of sighash operations,\n\u003e which prevents the network from crashing when large transactions are\n\u003e broadcast. Third, SW provides an efficiency gain for everyone who is not\n\u003e verifying signatures, as these no longer need to be downloaded or\n\u003e stored. SegWit is an enabling technology for the Lightning Network,\n\u003e script versioning (specifically Schnorr signatures), and has a number of\n\u003e benefits which\n\u003e are unrelated to capacity [4].\n\u003e\n\u003e Third, the Lightning Network, which allows users to transact without\n\u003e broadcasting to the network, is complete [5, 6] and awaits the\n\u003e activation of SegWit. For those users who are able to make a single\n\u003e on-chain transaction, it is estimated to increase both capacity and\n\u003e scalability by a factor of ~1000 (although these capacity increases will\n\u003e vary with usage patterns). LN also greatly improves transaction speed\n\u003e and transaction privacy.\n\u003e\n\u003e Fourth, Transaction Compression [7], observes that Bitcoin transaction\n\u003e serialization is not optimized for storage or network communication. If\n\u003e transactions were optimally compressed (as is possible today), this\n\u003e would improve scalability, but not capacity, by roughly 20%, and in some\n\u003e cases over 30%.\n\u003e\n\u003e Fifth, Schnorr Signature Aggregation, which shrinks transactions by\n\u003e allowing many transactions to have a single shared signature, has been\n\u003e implemented [8] in draft form in libsecp256k1, and will likely be ready\n\u003e by Q4 of 2016. One analysis [9] suggests that signature aggregation\n\u003e would result in storage and bandwidth savings of at least 25%, which\n\u003e would therefore increase scalability and capacity by a factor of 1.33.\n\u003e The relative savings are even greater for multisignature transactions.\n\u003e\n\u003e Sixth, drivechain [10], which allows bitcoins to be temporarily\n\u003e offloaded to 'alternative' blockchain networks (\"sidechains\"), is\n\u003e currently under peer review and may be usable by end of 2017. Although\n\u003e it has no impact on scalability, it does allow users to opt-in to\n\u003e greater capacity, by moving their BTC to a new network (although, they\n\u003e will achieve less decentralization as a result). Individual drivechains\n\u003e may have different security tradeoffs (for example, a greater reliance\n\u003e on UTXO commitments, or MimbleWimble's shrinking block history) which\n\u003e may give them individually greater scalability than mainchain Bitcoin.\n\u003e\n\u003e Finally, the capacity improvements outlined above may not be sufficient.\n\u003e If so, it may be necessary to use a hard fork to increase the blocksize\n\u003e (and blockweight, sigops, etc) by a moderate amount. Such an increase\n\u003e should take advantage of the existing research on hard forks, which is\n\u003e substantial [11]. Specifically, there is some consensus that Spoonnet\n\u003e [12] is the most attractive option for such a hardfork. There is\n\u003e currently no consensus on a hard fork date, but there is a rough\n\u003e consensus that one would require at least 6 months to coordinate\n\u003e effectively, which would place it in the year 2018 at earliest.\n\u003e\n\u003e The above are only a small sample of current scaling technologies. And\n\u003e even an exhaustive list of scaling technologies, would itself only be a\n\u003e small sample of total Bitcoin innovation (which is proceeding at\n\u003e breakneck speed).\n\u003e\n\u003e Signed,\n\u003e \u003cNames Here\u003e\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e 2015-December/011865.html\n\u003e [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/\n\u003e [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/\n\u003e [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/\n\u003e [5]\n\u003e http://lightning.community/release/software/lnd/\n\u003e lightning/2017/05/03/litening/\n\u003e [6] https://github.com/ACINQ/eclair\n\u003e [7] https://people.xiph.org/~greg/compacted_txn.txt\n\u003e [8]\n\u003e https://github.com/ElementsProject/secp256k1-zkp/blob/\n\u003e d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594\n\u003e [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/\n\u003e [10] http://www.drivechain.info/\n\u003e [11] https://bitcoinhardforkresearch.github.io/\n\u003e [12]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e 2017-February/013542.html\n\u003e\n\u003e  ==== End of Roadmap Draft ====\n\u003e\n\u003e In short, please let me know:\n\u003e\n\u003e 1. If you agree that it would be helpful if the roadmap were updated.\n\u003e 2. To what extent, if any, you like this draft.\n\u003e 3. Edits you would make (specifically, I wonder about Drivechain\n\u003e thoughts and Hard Fork thoughts, particularly how to phrase the Hard\n\u003e Fork date).\n\u003e\n\u003e Google Doc (if you're into that kind of thing):\n\u003e https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc\n\u003e mCq-jjBOQSVH-A/edit?usp=sharing\n\u003e\n\u003e Cheers,\n\u003e Paul\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/8b9806dd/attachment-0001.html\u003e"}