I wish to explain my stance on the BIP110 hard fork resulting from the failed soft fork attempt. After that, I’ll explain what I’ve done so far with my code and products.
Principles
I don’t really wish to disparage those who followed their principles and decided to follow the BIP110 hard fork, as I share some of those particular principles.
But other conflicting principles (related to digital scarcity) lead me to accept that the soft fork failed and this BIP110 hard fork is futile.
Digital Scarcity
A hard fork restarts the network effect, damages the quality of the money, destroying digital scarcity.
Money does not only have technical properties, but social properties as well (the network of people). The damage/threat Bitcoin is experiencing (difficulty for the poor to run a node because of the burden of spam; risk of illicit material on chain inviting state attack; capture of the development team and risk of further unwanted changes to the Core client) is not as great as the damage to the quality of Bitcoin as money if it has a contentious hard fork in its history.
So I cannot call the BIP110 chain the real Bitcoin unless the real Bitcoin dies, or is imminently dying. If that does happen, we would lose the immaculate chain, and all shitcoins become contenders for money based on technical properties, as the massive lead in network effect that the current chain has would be lost, and with it, digital scarcity.
When a Hard Fork is needed
A hard fork would be promising if it fixes a critical defect, like an inflation bug (that happened), but not one where, say, a hack is reversed (Ethereum DAO hack), or if principles get fractured (eg BCH, BIP110 Coin).
To elaborate:
If there is an issue where the existing chain would suddenly die, then a hard fork fix would be unanimous by default, since not accepting a hardfork would lead to those resisting having nothing (since the original chain dies).
So the fix would result in no split, actually, unless there are various competing fixes.
Why I sympathise
I understand that some people just cannot accept what has happened to the existing chain, and in their eyes consider it dead. In that case, adopting the hard fork makes sense – they are following their principles.
But for other hard forks, even though the individuals involved are following their principles, I don’t sympathise because I don’t share those principles at all. Eg:
- Bitcoin needs bigger blocks and low fees for all so p2p payments can be made by anyone, eliminating retail banks. (Bitcoin Cash)
(I don’t believe ending retail banking is the purpose of Bitcoin; I believe the purpose is eliminating central banking, replacing fiat money, and introducing sound money for the world) - Craig Wright is Satoshi (BSV)
- Bitcoin needs faster payments (Litecoin)
- Several others that are even dumber
What I did with my code
I have developed a node package software called Parmanode (similar in design to Start9, Umbrel, MyNode, RaspiBlitz), as I was frustrated with troubleshooting code that I didn’t write. I went all in, and it joyfully consumes a lot of my time.
When Bitcoin Knots became available, I supported the idea of having various clients rather than one dominant implementation (Core).
Later, when the spam issue got out of hand and I lost faith in the Core development team, I made Bitcoin Knots the default, but didn’t remove Core as an option.
Later, when Core v30 came out, I considered it malware, and didn’t have that version as an option; the latest being v29.3. That version can be run with a filter-ordinals patch to minimise sharing of transactions that are non-monetary – again, optional.
Knots supported the BIP110 soft fork, and I was happy with that, and supported it through my code, but never removing the choice from the users. If the Bitcoin Core team can modify users’ default settings against majority support, why should I be criticised for making changes to the defaults of my own software that’s freely available?
Later, the BIP110 soft fork failed, and now there is a hard fork with a different mining algorithm. I explained why I don’t support it in principle, but sympathise with those that do. In my Parmanode software, I will make Core v29.3 the default, and Bitcoin Knots running the hard fork is still available. I don’t wish to push against this hard fork with my code, as many Parmanode users have switched to that chain, or at least, like me, are not selling those forked coins and need access to them.
Currently, only one version of Bitcoin can be run with Parmanode, but I’ll figure something out to allow both at some point; it’s just too early, and I’m waiting to see what happens.
If you would like to argue with me about some of the things I’ve said, I welcome you to write (see my contact page). If the discussion is good, I may add it to the bottom of this page.
What I did with my products
ParmanodL laptops will be available with Bitcoin Core as default and Bitcoin Knots as optional on request, just like the parmanode software for those who DIY.
ParmaKnots miniPC nodes are going to remain as long as the hard fork has life, and a Core-based miniPC brand will be made.
ParmAirGap signing laptops are unaffected; they are agnostic to the chain.
ParmaDrive home data servers will also, like ParmanodL, have Core as the default.
PrivateHash has switched to mining on the legacy chain, not the BIP110 fork. An option may become available one day, but currently renting Blake2b hash for the BIP110 chain isn’t well developed.
Additional points to be added over time…
- This is not the only chance to hard fork. If something goes terribly wrong, a hard fork at that time can be done to rescue the chain.
- People leaving Bitcoin (hard fork followers) because of spam is worse for Bitcoin (reduced network effect) than the spam itself, with the added friction to run a node.