Cyber Security

BIP-110 Probability Of Failure As Mining Signage Remains Less Than 1%

This guest post is by Jason HughesVP of Development and Engineering of Ocean Mining. The views expressed are entirely his own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine. The subject appeared first on X.com and published with permission of the author.

Let me start by saying that I am not a BIP110 expert, nor am I against BIP110. If it really succeeds as something that gains true consensus within the network and ends up being enforced by the majority of the network… great. If so, then we will go with it because the network has spoken and accepted it, and all nodes, including non-BIP110 nodes, will be pulled to ride. Unfortunately for proponents of the proposal, that’s not the case yet by any measurable metric, and there doesn’t seem to be any way to suggest that will change, either.

There has been a lot of misinformation about the whole thing, especially in the case of mining. A few quick key points to briefly counter the hyperbole from supporters: BIP110 is NOT inevitable. It MAY fail. BIP110 can and will cause a chain split/fork in a low hashrate scenario. BIP110 is NOT without risk for miners who choose to take it. Miners who don’t support BIP110 aren’t suddenly “inactive” blocks just because an unaccepted proposal just happened. You are not a bad or bad person just because you don’t like or support BIP110. (The fact that I feel the need to point out that last part hurts…)

I was going to write a long post to help keep miners informed of things they need to be aware of as all this happens… before realizing I had already done so months ago, as a document I approved that I hoped could be released as an educational piece for OCEAN miners. Sadly, it was never published. So I went ahead and updated it, and here it is.

Also, remember that this was written months ago, intended to be as anonymous as possible in an effort to make it acceptable as a company post. That attempt failed, so I am posting it as a personal document today. As a miner making important decisions about your operation, you need to be aware of all of this without the sugarcoating and, frankly, misleading information from some of the BIP110 supporters. You have to be careful and decide what is right for you.

While there is misinformation from the opposition as well, nothing I have seen is nearly as bad as the premature victory claims and hyperbole associated with the BIP110 side. Summarizing my document a bit, my personal suggestion to miners is this: Signal if you support BIP110. Don’t show if you don’t support BIP110 or don’t care. Either way, monitor the network in /around/before blocking 961632.

If you keep seeing blokes not showing signals from the big pools, you can be sure they won’t suddenly decide to throw away millions of dollars worth of revenue to back off and sign BIP110. If they do, by chance, start signing BIP110, you should monitor that and consider changing as needed to stay on the heaviest chain. The bottom line is that, in reality, only one side can win. Either BIP110 succeeds, and non-BIP110-side miners fail, or BIP110 fails, and non-BIP110-side miners succeed.

Moving on, let’s dive into a small part of my mind.

FAST FACT: Between 7 and 15% of Bitcoin Nodes show BIP110 support.

It depends on which average browser you look at… there’s no way to know for sure [how many BIP110 nodes are signaling support]. My private detective puts this number much lower, but that’s a discussion for another day. Suffice it to say, I think it is reasonable and fair to say that even 15% is not a majority.

“But Jason! The UASF made Segwit work on a few nodes!”

Yes, because many miners, merchants, users, etc., all really wanted Segwit. There was great economic and social weight behind it. Without rehashing the whole thing, as many resources on the pre-BIP110 topic should be read, suffice it to say that the functionality of BIP110 and Segwit is not at all the same, as many have already said. Segwit, for example, has moved to its UASF location with about 1/3rd the hashrate of the network that already shows support. With that kind of support, the UASF helping to push the MASF over the tipping point makes a lot of sense. It doesn’t make sense here with BIP110.

FAST FACT: 0.6% of blocks in the last 60 days have shown support for BIP110.

[0.6% is a] a very good difference even with the low Segwit support. Yes, I know it has gone up a bit in the last few weeks, but no new ones have come in recently. A more clearly monitored hashrate for one of the same small supporters.

Something to keep in mind is that BIP110 signature mining with DATUM in OCEAN carries absolutely no risk in mining up to the fork point at block 961632. Costs are negligible, as you are effectively guaranteed to pay rental costs, etc.

It’s amazing that the ability to do that exists, and I wouldn’t have it any other way… but it’s just something to keep in mind when you measure signings from such blocks in the grand scheme of things from a reward perspective, money on the table.

“But Jason! The miners have no incentive to show up until the last minute!”

I also see no evidence to suggest that this would be the case. Honestly, I disagree with the premise, because it’s not in the best interest of the mining pool to destabilize the network that way. Part of the reason for early signing and lock-in periods is to help coordinate development in a smoother manner. Waiting until the last minute throws away that benefit entirely. I see no compelling reason or objection to doing so.

Continuing on this, as part of my personal monitoring node setup, I specifically monitor areas known to various organizations, such as other mining pools, exchanges, major lightning sites, vendors, etc. A lot of them are monitored with clear permission and authentication/communication.

FAST FACT: All the major mining pools I currently monitor are running a variant of Bitcoin Core v30 or v31 (except OCEAN).

To expand on that, most [mining pools] they have updated their nodes since the expansion of BIP110 release, even since the release of Knots 29.3. Additionally, it is known that many mining pools use modified versions of their node software to accommodate the various needs of their particular infrastructure. Such changes will need to be submitted to a BIP110 compliant client, tested, tested, and implemented in advance. There is currently no evidence that this is the case.

As far as I know, the lakes know but don’t care.

“But Jason! Miners don’t compromise! Nodes are there! Otherwise, they’ll just withdraw half!”

This is one of the funniest and funniest arguments I’ve heard from the pro-BIP110 crowd. Comparing a consensus change that can be forced on the network by miners and accepted by 100% of the existing nodes (a soft fork), with a hard fork that no existing node will accept… makes absolutely no sense. T

enforcement rules (like BIP110): Soft fork, can be enforced by miners if they choose to do so. Loose rules (like half cancellation): A hard fork, cannot be enforced by miners without 100% buy-in from the entire network… which is unlikely. Comparing the two is, frankly, just silly.

“But Jason! If you don’t upgrade to the latest consensus rules, you’re not safe! You’re going to lose money! You’re going to mine invalid blocks! [insert additional hyperbole here]!”

This can be true for a change in consistency, well, consistency. Although BIP110 has made a valiant effort to find that consensus, it has yet to have a measurable majority in what may now be the 11th hour. Not in nodes, not in hashrate, not in social layers (consensus.health has a cool look where you’ll find me).

If somehow BIP110 achieves 51%+ network hashrate on/before block 961632… then, fine. It is enforced, since as a soft fork most miners can’t enforce it collectively without a fully accepted URSF (actually a misnomer, as this would be a hard fork).

“But Jason! It won’t work to compromise because it’s already compromised! You have to give it a chance!”

First of all… no, I don’t, although I have. Second, it’s a quick proposal that we never had time to try and find a real compromise. It has been 7 months since the first BIP110 client was released. There are only 3 weeks left before the “mandatory” signing starts from now (less by the time you read this). 90% of the available time has passed without a change in the nationality of any eligible players. If it hasn’t received enough acquisitions in the past 7 months, it won’t be able to do so in the next 3 weeks.

“But Jason! CSAM! CSAM! Rapists! CSAM!”

I’ll be the first to say, even I myself jumped the gun here early when Core proposed its OP_RETURN change. Personally, I was expecting something surprising to hit the chain immediately, and as far as I know, that hasn’t happened yet. Is it still possible? Yes, I think so.

But when considered from a technical point of view, byte-for-byte the same parallel data can be stored in the current thread or chain of BIP-110 without much problem… this particular argument of BIP-110 is easy for me right now.

Do I want CSAM on chain? Of course not. Am I a pedophile if I don’t support BIP110? And not.

Concluding thoughts

I could go on and on and on, but I’ll stop here. I’ve wasted enough time on this. I’m sure I’ve done a lot to offend both sides of the BIP110 debate on this point, as I don’t accept either position. I’m sure I’ll catch flak from all angles just for speaking my mind about it.

Overall, I mostly think it was stupid to approach solving the real problem (the default OP_RETURN change in Bitcoin Core) with an advanced anti-spam proposal based on a fork… which might not be able to stop spam, ambiguous data, etc. 🤦‍♂️ (Yes, I know, proponents will say it’s not that the arguments don’t match what data is coming out… if you’re right.)

I’ll close with the admission that I could be wrong. I’m not Nostradamus, and I can’t accurately predict the outcome with 100% certainty. I can only go by what the data tells me, so I’m giving BIP110 success less than a 5% chance of actually succeeding… and I’m looking at that liberally. You can take my opinions on this as you wish, but I strongly recommend that you don’t discount the actual data points, stay alert, and do what’s best for you and your mining profit. Don’t be on either side of the debate, and make up your own mind.

Here is a link to the same document linked above for easy access.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button