Back in February I wrote a piece on then big block flavour of the month, Bitcoin Classic.
I was frustrated that the approach of rival implementations to Bitcoin Core was basically to lift most of the work of the core development team, make a few simple tweaks, and then try and push their implementation as the saviour of Bitcoin.
So I laid down a gauntlet, instead of being a cheap cover band, actually write some code that showcases your abilities and proves your worth. Do that, and a rival implementation could earn the respect and credibility essential to advance their agenda.
Segregated Witness (SegWit) is a clever way to almost double Bitcoin’s capacity without increasing the block size, while also solving other problems such as transaction malleability. It was widely agreed that SegWit was a win win.
Fast forward to now and SegWit has been developed, fully tested and is ready to be implemented as a soft fork.
Great news you would think, except if you go to the big blocker parts of the Internet, suddenly SegWit is considered dangerous!
The argument isn’t that SegWit is bad, it’s that it is way too complicated to be introduced as a soft fork, and should have been implemented as a hard fork. They also claim that the complexity of the code (over 500 lines), and compromises required as a soft fork will make Bitcoin really difficult to develop for in the future.
The developers at Bitcoin Core, who have delivered the solid dependability for which Bitcoin has become known, have collectively decided that SegWit was not just within their capabilities to write, but also to build upon in the future.
If any serious developer is arguing that Bitcoin is going to be too complicated for them after SegWit, they’re probably not a good enough developer that they should even be considering working on such a critical software. Anyone who isn’t a developer frankly needs to keep their concern to themselves, as they are not qualified to hold such a view.
I’d be a lot less harsh if SegWit had suddenly been announced and implemented under a shroud of secrecy. The Core developers said in December however, that SegWit would be coded as a soft fork.
If any rival team of developers disagreed with this approach they had a simple solution… write their own implementation of SegWit as a hard fork.
This would give them an opportunity to showcase their abilities, and give the community something to think about. If it was as simple and elegant as they say… they could have had the code ready months before Core, impressed us all with its elegance, and really built some momentum
What do we have instead? We have a small community determined to do everything in its power to block SegWit activation. It’s a shame that instead of sitting on the sidelines complaining, they didn’t take some initiative. They need to learn from this experience, as right now they just look like the petty children who have taken their ball and gone home because the game isn’t going their way.
photo credit: John Spooner Beware of the Troll via photopin (license)
John Hardy
Longtime Bitcoin advocate.
Email [email protected]
Donations welcome: 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE
Latest posts by John Hardy (see all)
- The great P2PK Bitcoin heist. Millions of Bitcoins WILL be stolen, but should we even try to stop it? - 24 Aug 2018
- Follow up: Bitcoin Cash has 51% attack vulnerability double jeopardy - 31 Jul 2018
- Bitcoin rival has a major vulnerability which could help Bitcoin miners to destroy it in 2020 - 30 Jul 2018
