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