Bitcoin Scaling Roadmap which was created by Greg Maxwell on Dec 7, 2015 now a bitcoin software developer Paul Storcz wants to update it. In a few crucial ways, the scaling roadmap was succeeded. Whereas the developer thinks there are few things needs to be revised. More likely to remove the achievements till date, now need to be updated with the future plans. And implement a timeline for a protocol like the Schnorr signatures and lightning networks.
Sztorc explains, “Unfortunately, the Dec 2015 roadmap is now 19 months old — it is quite obsolete and replacing it is long overdue”. For instance, as the future improvement, it highlights the older materials and not mentioned of new high likelihood improvements. It might even hold mistakes of Segwit fraud proofs.
“To understand the old roadmap properly, one must already be a technical expert. For me, this conquest the complete point of having one in the first place.”
Eliminating accomplished tasks and adding upcoming developments.
With the Sztorc’s intention to revise the roadmap, he stays open to feedbacks and edits to his first own draft. The completed things should be removed in the Sztorc’s view point which includes Compact Blocks (BIP 152), Versionbits (BIP 9) and Check Sequence Verify (BIP 112). Along with Sztorc discussing the Segwit Protocol is the main part of the revised roadmap. Later on, the developer explains a rough timeline for Schnorr signature, transaction compression, and lightening network.
“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 main chain Bitcoin.”
Sztorc’s opinion on Hard Fork Scaling
The conclusion of the Sztorc letter says, “may not be sufficient”. Then he adds that it might be necessary to hard fork the network and enhance the block size limit.
He again adds, “Such an increase should take advantage of the existing research on hard forks, which is substantial”. “Precisely, there is some agreement that Spoonnet is the most striking option for such a hardfork. Presently, there is no agreement on a hard fork date. But there is a rough accord that one would necessitate at least six months to organize efficiently, which would place it in the year 2018 at initially”.