03 March 2016 – Dashjr, Bitcoin Core Developer, has made a novel proposal to solve the risk associated with the upcoming Bitcoin halving in July on development mailing lists. Instead of implementing a scaling solution, he suggests making adjustments to the code that governs difficulty of mining blocks. Bitcoin development has slowed significantly amidst controversy generated in the community over exactly how Bitcoin should scale, and the hard fork Dashjr proposes acts as a contingency plan in case this trend continues.
Read Also: Visa is Looking for Blockchain Developers
Dashjr Proposal a Band-Aid Fix
While this hard fork proposal would solve a real potential problem of miners dropping out of the Bitcoin network in response to the upcoming halving, the systemic failures that make this an issue of note should be much more pressing to the Core devs.
Bitcoin Core has a track record of responding sensitively to the opinions of their end-users. They have delayed implementation of a scaling solution over community disagreement, relayed mixed messages on adoption of the development roadmap proposed by the Bitcoin Consensus Round-table, and been paralyzed by the negative responses to their development proposals. This lack of decisive action on Core’s part has started to affect the long-term viability of the Bitcoin specification. Blocks are quickly reaching the current 1MB size limit, and a lack of any scaling solution being rolled into Core due to controversy has prevented the network from compensating for this, as alternative Bitcoin implementations still carry a minority of nodes and hash power.
This stagnation has made, among other things, miners leaving Bitcoin for more attractive (read: profitable) uses of their hash power a real risk. Dashjr points out the negative impact this would have succinctly in his Mailing list proposal:
“For example, if 50% of miners dropped off the network, blocks would be every 20 minutes on average and contain double the transactions they presently do.”
More transactions in each block means more blocks are hitting the hard limit, necessitating a fast change to prevent abyssal transaction and confirmation times. Something which would be prevented by implementing any scaling solution at all (even if it isn’t the most attractive or robust,) rather than holding off as a form of lip-service to competing interests in the Bitcoin ecosystem. The sentiment from the Core developers that they need to prepare for disaster scenarios rather than preventing them because it may cause community backlash is telling of the toxic environment Bitcoin Politics has created for anyone trying to further the software.
How do you think Bitcoin Core should handle the problem of halving moving forward? Let us know in the comments!
Images courtesy of Wikimedia Commons, Bitcoin Core, Blockchain.info
