This is a guest post by Jason HughesVice President of Development and Engineering in Ocean mining. The opinions expressed are entirely his own and do not necessarily reflect the views of BTC Inc. Or Bitcoin Magazine. The article Originally appeared on X.com It is published with permission of the author.
Let me start by saying that I am not a professional BIP110And I’m not against BIP110. If it actually works as something that gains real consensus within the network and ends up being enforced by a majority of the network… that’s great. If so, we will approve it because the network has spoken and accepted it, and all nodes, including non-BIP110 nodes, will be pulled during the flight. Unfortunately for the proposal’s proponents, this simply is not currently the case by any measurable measure, and it does not appear to have a trajectory that suggests that will change either.
There has been a lot of misinformation about this whole thing, especially in the context of mining. Some quick key points to briefly counter some of the hyperbole from supporters: BIP110 is not inevitable. You can fail. BIP110 can cause a chain split/fork in case of lower hash rate. BIP110 is not without risks for miners who choose to adopt it. Miners who don’t support BIP110 aren’t suddenly mining “invalid” blocks just because there’s a proposal that hasn’t been approved yet. You are not a bad or evil person just because you do not like or support BIP110. (The fact that I feel the need to point out that last part is actually kind of sad…)
I was going to write a long post to help keep miners up to date on things they need to stay aware of while all this is going on…before I realized I had already done so months ago, as a document I authored and hoped would be put out as an educational piece for miners at OCEAN. Unfortunately, it was never published. So I went ahead and updated it, okay, Here is.
Again, keep in mind that this was written months ago, and was intended to be as neutral as possible in an attempt to make it passable as a company post. That effort failed, so I’m publishing it as a personal document today instead. As a miner making important decisions about your operations, you need to be aware of all of this without the embellishment and, frankly, outright misinformation coming from some BIP110 supporters. You must be vigilant and decide what is right for you.
While there is certainly some misinformation from the opposition as well, nothing I have seen is nearly as egregious as the very early claims of victory and accompanying hyperbole pushed by the BIP110 side. Summing up my doc a bit, my personal suggestion to miners is this: indicate if you support BIP110. Don’t tag if you don’t support BIP110 or don’t care. In either case, monitor the network on/around/before block 961632.
If you keep seeing blocks with no signals from the major pools, you can be reasonably sure that they won’t suddenly decide later on to throw away millions of dollars in revenue to roll back and signal BIP110. If, by chance, they do start indicating BIP110, you should keep an eye on that and consider switching as required to stay on the heaviest string. The point is that, realistically, only one side can win. Either BIP110 succeeds, and non-BIP110 miners fail, or BIP110 fails, and non-BIP110 miners succeed.
Moving forward, let’s dig into a little bit of my rationale.
Fast fact: Between 7 and 15% of Bitcoin nodes indicate BIP110 support.
Depending on which central crawler you look at…there’s no way to know for sure (number of BIP110 nodes indicating support). My crawler put that number much lower, but that’s a discussion for another day. Suffice it to say, I think it is logical and correct to say that even 15% is not a majority.
“But Jason! UASF activated Segwit with fewer nodes!”
Yes, because many miners, traders, users, etc., all wanted Segwit already. There was enormous economic and societal weight behind this. Without rehashing this whole thing, since a lot of the resources on this topic prior to BIP110 are worth reading, suffice it to say that the BIP110 and Segwit activations are not exactly comparable, as many have already pointed out. For example, Segwit entered its UASF region with roughly a third of the network hash rate already indicating support. With this kind of support, helping UASF push MASF to the tipping point made perfect sense. It doesn’t make sense here for BIP110.
Fast fact: 0.6% of blocks in the last 60 days indicated support for BIP110.
(0.6%a) A very stark contrast even with Segwit’s low baseline support. Yes, I know it has increased a bit in the last couple of weeks, but there are no new arrivals. Only the hashrate rented more clearly than one of the small backers themselves.
What should be taken into consideration is that mining BIP110 signal blocks via DATUM on OCEAN carries virtually no risk to the miner until the fork point at block 961632. The cost is negligible, as you are guaranteed to recover your rental costs etc.
It’s great that the ability to do this exists, and I wouldn’t have it any other way…but just something to keep in mind when weighing signals from such blocks in the grand scheme of things from a risk-reward and money-on-the-table perspective.
“But Jason! The miners have no incentive to signal until the last minute!”
I also see no evidence to suggest that this might be the case. Personally, I disagree with this premise, because it is not in the interest of the mining pool to destabilize the network in this way. One of the reasons for sending early signals and lock-in periods is to help coordinate upgrades in a smooth manner. Waiting until the last minute completely negates that benefit. I see no compelling justification or positive side for doing so.
In continuation of this, as part of my personal node monitoring setup, I specifically monitor nodes that are known to belong to various entities, such as other mining pools, exchanges, large lightning nodes, traders, etc. The vast majority of them are monitored with explicit permission and confirmation/coordination.
Quick fact: All major mining pools I monitor are currently running some version of Bitcoin Core v30 or v31 (except OCEAN).
To expand on this, most mining pools have updated their nodes since BIP110 rolled out, and even since Knots 29.3. Additionally, many mining pools are known to run modified versions of their contract software to facilitate the different requirements of their infrastructure. Such changes must be moved to a BIP110 compliant client and tested, evaluated and deployed in advance. I currently see no evidence that this is currently the case.
As far as I can tell, the pools are aware but ignore.
“But Jason! Miners don’t set consensus! Nodes do! Otherwise, they’ll just cancel the halvings!”
This is one of the funniest and most ridiculous arguments I’ve heard from the pro-BIP110 crowd. Comparing a consensus change that could be unilaterally imposed on the network by miners and accepted by 100% of existing nodes (soft fork), with a hard fork that no existing node would accept…is disingenuous at best. T
Hardening rules (such as BIP110): Miners can force a soft fork if they choose to do so. Relaxing rules (e.g. canceling halving): Miners cannot perform a hard fork without 100% of the entire network actively opting in… which is unlikely to happen. Comparing the two is honestly just stupid.
“But Jason! If you don’t upgrade to the latest consensus rules, you’re insecure! You’ll lose money! You’ll be mining invalid blocks! You’ll (insert additional exaggeration here)!”
This would be true for consensus change. While BIP110 has made valiant efforts to obtain this consensus, it has yet to secure any measurable majority in what is now arguably the eleventh hour. Not in nodes, not in hash rate, not in social classes (Compatibility. health He has a great look over there where you’ll find me in the middle).
If BIP110 somehow gets 51%+ of the network hash rate on/before block 961632… then, oh well. It is enforced, because as a soft fork, the majority of miners can enforce it unilaterally in the absence of a fully approved URSF (which is effectively a misnomer, as this would be a hard fork).
“But Jason! You can’t get consensus by already having consensus! You have to give it a chance!”
First…no, I don’t, even though I did. Second, it is a hasty proposal that has not had time to even attempt to gain real consensus. It has been 7 months since the first BIP110 client was released. There are approximately 3 weeks left before the “mandatory” signal starts as of now (less by the time you read this). 90% of the available time has passed with no change in overall sentiment from any of the players involved. If you haven’t gotten enough credit in the past seven months, you’re unlikely to do so in the next three weeks.
“But Jason! CSAM! CSAM! Pedophile! CSAM!”
I’ll be the first to say, even I personally overestimated the risks here early on when Core suggested changing its OP_RETURN. I personally expected something particularly terrible to happen to the series almost immediately, and as far as I know, that hasn’t happened yet. Could it still happen? Yes, I think.
But looking from a technical perspective, the same arbitrary per-byte contiguous data could end up being stored in the current chain or BIP-110 chain without much problem… This particular argument for BIP-110 doesn’t sit well with me at this point.
Do I want CSAM in the chain? Of course not. Am I gay if I don’t support BIP110? Also no.
Concluding thoughts
I could go on and on, but I’ll stop here. I’ve wasted enough time on this. I’m sure I’ve done a lot to upset both sides of the BIP110 debate at this point, as I don’t take either position. I’m sure I’ll get criticized from all angles just for daring to express my opinion on this matter.
Overall, I mostly think it was silly to take a real issue (default OP_RETURN change in Bitcoin Core) with a maximum soft fork proposal based on an anti-spam statement… which can be proven to not stop spam, arbitrary data, etc. 🤦♂️ (Yes, I know proponents will claim it’s not about spam… and they’ll also make semantic arguments that it stops data too… neither of which seems to be true.)
I’ll conclude by admitting that I may be wrong. I am not Nostradamus, and I cannot accurately predict the outcome with 100% certainty. I can only go with what the data tells me, so I’m giving BIP110’s success less than a 5% chance of actually succeeding…and I consider that generous. You can take my opinions on this however you want, but I highly recommend not dismissing actual data points, staying vigilant, and doing what is best for you and your mining revenue. Don’t be offended by either side of the debate, and make your own decisions.
Here’s a link to the same document linked above for easy access.
