Top_Header

Paul Sztorc Suggests Revising Bitcoin’s Scaling Roadmap




Sztorc

On July 10 Hivemind’s chief scientist, and Bloq developer, Paul Sztorc, announced updating Bitcoin’s scaling roadmap created in December 2015 to a newer version. Sztorc believes the current roadmap needs revision and is “simply too old to serve this function any longer.”

Also read: Hivemind, Bloq Developer Paul Sztorc Discusses Bitcoin & Sidechains


Revising the Bitcoin Scaling Roadmap

Paul Sztorc Suggests Revising Bitcoin's Scaling Roadmap
Hivemind’s chief scientist, and Bloq developer, Paul Sztorc.

Bitcoin software developer Paul Sztorc wants to update the Bitcoin Scaling Roadmap created by Greg Maxwell on Dec 7, 2015. Sztorc says Maxwell’s scaling roadmap succeeded in a “few crucial ways,” but the developer thinks there needs to be a revision. One that removes what has been achieved so far, updates it with future plans and outlines a timeline for protocols like the Lightning Network and Schnorr signatures.  

“Unfortunately, the Dec 2015 roadmap is now 19 months old it is quite obsolete and replacing it is long overdue,” explains Sztorc via the Bitcoin developer mailing list. “For example, it highlights older items (CSV, Compact Blocks, Versionbits) as being future improvements, and makes no mention of new high-likelihood improvements (Schnorr) or misemphasizes them (LN). It even contains mistakes (Segwit fraud proofs).”

To read the old roadmap properly, one must already be a technical expert. For me, this defeats the entire point of having one in the first place.

Removing Completed Tasks and Adding Future Developments

Following Sztorc’s reasoning for wanting to revise the roadmap, he provides his own first draft and says he is open to edits and feedback. Some of the things that have been completed and should be removed in Sztorc’s opinion include Versionbits (BIP 9), Compact Blocks (BIP 152), and Check Sequence Verify (BIP 112). Then Sztorc goes onto discussing the Segwit protocol as the first part of the revised roadmap. Below the Segwit section, the developer then describes a rough timeline for Schnorr signatures, the Lightning Network, and transaction compression.

Paul Sztorc Suggests Revising Bitcoin's Scaling Roadmap

After these focal points, Sztorc has outlined his proposal called Drivechainwhich allows bitcoins to be temporarily offloaded to ‘alternative’ blockchain networks.” Sztorc told Bitcoin.com this past February he’s dedicated most of his time to the Drivechain project. Sztorc describes Drivechain’s potential in his mailing list announcement saying;

Although it has no impact on scalability, it does allow users to opt-in to greater capacity, by moving their BTC to a new network (although, they will achieve less decentralization as a result). Individual drivechains may have different security tradeoffs (for example, a greater reliance on UTXO commitments, or Mimblewimble’s shrinking block history) which may give them individually greater scalability than mainchain Bitcoin.

Sztorc’s Thoughts on Hard Fork Scaling

Sztorc concludes his letter by saying his outlined proposals “may not be sufficient.” The Drivechain developer then adds that it may be necessary to hard fork the network and increase the block size limit.

Such an increase should take advantage of the existing research on hard forks, which is substantial,” Sztorc adds. “Specifically, there is some consensus that Spoonnet is the most attractive option for such a hardfork. There is currently no consensus on a hard fork date, but there is a rough consensus that one would require at least six months to coordinate effectively, which would place it in the year 2018 at earliest.”

What do you think about Paul Sztorc’s proposal to revise Bitcoin’s scaling roadmap? What do you think about his Drivechain project? Let us know in the comments below.


Images via Shutterstock, Pixabay, and Twitter. 


Need to calculate your bitcoin holdings? Check our tools section.



Source


Related posts

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!