I used to blame the developers for being too slow to find a solution to the scalability issue. Now that we have one (well, sort of...), I may start to blame the miners for being too slow to implement it. At this rate, we'll be lucky if SegWit is adopted by Spring.
firstly ill repeat
its like Windows. never blindly install and run a new version of windows until its atleast released its first batch of patches
and then add
yet other proposals could have been released sooner..
segwit is just kicking the stone down the road.
at the moment pre-segwit we are getting ~2500tx (standard tx mix)
at the moment pre-segwit we are getting ~2100tx (standard/multisig tx mix)
only expect ~4500tx IF.. EMPHASIS:
IF 100% of users use segwit.yep the 1.8x of ~2500tx (standard tx mix) =~4500 IF
100% of users use segwit.
yep the 2.1x of ~2100tx (standard/multisig tx mix) ~4500 IF
100% of users use segwit.
but guess what.
if you look back to 2009-2013, transactions were leaner with the estimates of 4500tx (remember the good old days of 7tx/s hype)
thats right we are just going backwards to original expectations of 2009-2013..
and only able to reach OLD expectations IF EVERYONE used segwit
but a proper scalability of 2mb base 4mb weight. would offer ~5000tx without segwit and ~9000tx with segwit.
and making it dynamic means we are not waiting months/years for PEOPLE to decide to allow other people to download a change. it would happen as part of the network. meaning no political name calling or oliver twist scripts of "please sir can i have some more"
but hey we seem to have too many people protecting devs rather then bitcoins diversity and utility.