BIP-110 On Failure Mode When Miner Signaling Remains Below 1%


This is a guest post Jason HughesVP of Development and Engineering to Ocean Mining. The opinions expressed are their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine. Story appeared first on X.com and is published with the permission of the author.

Let me start by saying that I am no expert BIP110and I am not anti-BIP110. If it’s successful as something that gets a real deal on the network and is followed by more networks… cool. If so, then we will go with them because the network will talk and agree, and all nodes, including non-BIP110 nodes, will be pulled to climb. Unfortunately for proponents of the idea, that’s not the case with any measurable metric, and it doesn’t seem to have any indication that it’s going to change, either.

There has been a lot of misleading information about this whole thing, especially when it comes to mining. A few quick bullets to briefly refute the hyperbole from its promoters: BIP110 is NOT inevitable. It may fail. BIP110 can and will trigger a chain split/fork in low hashrate events. BIP110 has no risk for miners to choose to adopt it. Miners who do not comply with BIP110 are not suddenly blocked “unacceptable” just because an unapproved proposal exists. You are not a bad person or a bad person because you don’t like or support BIP110. (I feel the need to say that the last part is sad…)

I was going to write a long post to help keep miners informed of the things they need to know about what this looks like… before I realized I had already done it months ago, as a document I had written that I hoped could be posted as part of the miner’s training course at OCEAN. Unfortunately, it was not published. So I went ahead and edited it, and, Here it is.

Again, keep in mind that this was written months ago, designed to be as agnostic as possible in an attempt to make it acceptable as an industry service. That effort failed, so I’m posting it as my document today instead. As a miner making important decisions about your operations, you need to know all this without the sugar coating and, of course, false information coming from some of the opponents of BIP110. You have to be careful and choose what is right for you.

Although there is also misleading information from critics, nothing I have seen is as bad as the claims of success that have been made on the part of BIP110. To summarize my doc a bit, my advice to miners is this: Token if you support BIP110. Don’t show if you don’t agree with BIP110 or don’t care. In any case, check the net / around / before closing 961632.

If you continue to see blocks without signs from the big ponds, you can be sure that they will not suddenly decide in the future to drop millions of dollars to come back and show BIP110. If they do, by chance, they start showing BIP110, you need to monitor this and make adjustments as needed to stay on the heavy chain. The bottom line is that, frankly, only one side can win. Either BIP110 wins, and non-BIP110 miners fail, or BIP110 fails, and non-BIP110 miners win.

Moving on, let’s dive into a little bit of my thoughts.

TIP: Between 7 and 15% of Bitcoin Nodes support BIP110.

Depending on which central crawler you look at… there is no way to tell (how many BIP110 nodes are showing support). My secret crawler downloads this number, but that’s a discussion for another day. Suffice it to say, I think it is fair and accurate to say that even 15% is not a lot.

“But Jason! UASF started Segwit with a few nodes!”

Yes, because many miners, traders, users, etc., all wanted Segwit. There was a lot of economic and regional weight behind it. Without repeating the whole thing, since many things on this topic from before BIP110 should be read, it is enough to say that the activations of BIP110 and Segwit are not the same, as many have already said. Segwit, for example, entered its UASF session with about 1/3rd of the online support it already shows. With that kind of support, UASF helping to push MASF over that point made perfect sense. It is unclear here about BIP110.

TRAINING POINT: 0.6% of blocks in the last 60 days showed BIP110 support.

(0.6% is) a significant difference with the low support of Segwit. Yes, I know there has been a slight increase in the last few weeks, but no new entrants. Just clearly borrowed hashrates from one of the same promoters.

Something to keep in mind is that BIP110 block mining via DATUM on OCEAN is risk-free for the miner until the fork at block 961632. The cost is low, because you are guaranteed to get back the borrowed money, etc.

It’s amazing that such a possibility exists, and I wouldn’t have it any other way…

“But Jason!

I also see no evidence that this would be the case. Subjectively, I do not agree with this point, because it is not in the mining pool that wants to disrupt the network in this way. One of the reasons for the early display and closing times is to help improve the quality of the promotion. Waiting until the last minute negates the full benefits. I don’t see any good reason to do this.

Continuing this, as part of my node analysis process, I keep an eye on nodes that are known to belong to different organizations, such as mining pools, exchanges, major lightning, traders, etc. Most of them are controlled by automatic authorization and authentication/connection.

IMPORTANT NOTE: All major mining pools I manage are using Bitcoin Core v30 or v31 (except OCEAN).

Expanding on that, many (mining pools) have changed their nodes since the increasing BIP110 release, even since the release of Knots 29.3. In addition, it is known that many mining pools run modified software for their nodes in order to control the various requirements of their design. Such changes must be submitted to the client in accordance with BIP110, tested, tested, and submitted in advance. I do not see any evidence that this is the case.

As far as I know, the pools know but ignore it.

But Jason!

This is one of the funniest and most ridiculous arguments I have heard from the pro-BIP110 community. Comparing a consensus change that can be followed asynchronously by the network and miners and accepted by 100% of the existing nodes (soft fork), and a hard fork that none of the existing nodes will accept… is absurd. T

Crying rules (eg BIP110): A soft fork, can be followed by miners if they choose to do so. Loosening rules (like banning down): A hard fork, it cannot be forced by miners without 100% buy-in from the rest of the network… which is unlikely to happen. Comparing the two, frankly, is just silly.

“But Jason! If you don’t move up to the latest contract rules, you’re vulnerable! You’ll lose money! You’ll build illegal blocks! You’ll (insert some hyperbole here)!”

This may be true of the mutual agreement that is, the agreement. Although BIP110 has made an effort to match this, it does not have to have any statistical measurement for what is now the 11th hour. Not in places, not in hashrate, not in social groups (harmony. health they have some pretty good looks there where you’ll find me in the middle).

If somehow BIP110 gets 51%+ of network hashrate at/before blocking block 961632… then, great. It is forced, since like a soft fork many miners can force without valid URSF (like a misnomer, because this would be a hard fork).

“But Jason!

First of all…no I don’t, although I have. Second, it’s a quick idea that hasn’t had time to test and find a real deal. It has been 7 months since we released the first BIP110 customer. It’s about 3 weeks until the “official” sign starts from now (less if you read this). 90% of the available time has passed without a change of heart from the rest of the players. If they have not received the child fully in the last 7 months, it will not be possible in the next 3 weeks.

“But Jason! CSAM! CSAM! Sleepers! CSAM!”

I’ll be the first to say, even I said a lot about the risk here when Core decided to change OP_RETURN. I personally expected something really bad to hit the chain right away, and as far as I know, it didn’t. Can it still happen? Yeah, I think so.

But technically speaking, the same byte-for-byte data can be stored in the current chain or BIP-110 chain without much problem…

Do I need CSAM in the chain? Of course not. Am I a babysitter if I don’t comply with BIP110? Also no.

Final Thoughts

I could go on and on, but I’ll stop here. I’ve wasted enough time on this. I believe I’ve done a lot of annoying on both sides of the BIP110 debate at this point, as I’m not taking any opinions. I’m sure I’ll get in trouble for even daring to speak my mind.

Overall, I thought it was stupid to tackle the real problem (the OP_RETURN update in Bitcoin Core) with advanced anti-spam logic based on a soft fork… which can’t stop spam, bogus notifications, etc. to be perfect.)

I will close by admitting that I could be wrong. I am not Nostradamus, and I cannot accurately predict the outcome with 100% certainty. I can only go by what the data tells me, so I give BIP110 success at least a 5% chance of success… and I consider that to be generous. You can take my opinion on this however you want, but I recommend that you don’t discount the facts, be careful, and do what is best for you and your mining money. Don’t get carried away by either side of the argument, and make your own decisions.

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



Source link

Leave a Reply

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