BIP 110: update status to Closed #2245

BIP 110 was released on mainnet by Knots and entered its mandatory signaling period today (8th August 2026), rejecting non-signaling blocks. It split to a new chain and stalled.

One more question regarding the potential chain split and replay/coin-splitting issue:

Suppose a pre-fork UTXO exists on both chain tips. A transaction that is valid on MAIN but invalid under BIP-110 is confirmed on MAIN, leaving the UTXO unspent on the BIP-110 chain.

Later, the same UTXO could potentially be spent with a different transaction on the BIP-110 chain.

What consensus-level mechanism in BIP-110 prevents or handles this situation?

If there is no such mechanism, is replay protection / coin splitting entirely left to users, wallets, exchanges and other services to handle?

In particular, how should exchanges safely handle deposits and withdrawals during this period, given that the same pre-fork UTXO can represent value on both chain tips?

cc @jonatack @dathonohm @murchandamus

Calling something with a stalled chain Deployed in a bitcoin context is incredibly confusing for people reading the BIP. If the process mandates that it be called Deployed, the process should be fixed, rather than labeling something that has obviously failed "Deployed".

@TheBlueMatt I'm not opposed to updating BIP3. In this case, 110 was deployed; the criteria "an established project having deployed support for the BIP in mainnet software releases" is fulfilled. The following step would be to move it from deployed to closed, and not to remove it as you suggested in https://x.com/TheBlueMatt/status/2086218120998568098.

@avra911 Those questions aren't on-topic here. Edit: am marking my comment here as off-topic too. (I could be wrong, but I don't think 110 or the Knots implementation had replay protection.)

@avra911 Those questions aren't on-topic here. Edit: am marking my comment here as off-topic too. (I could be wrong, but I don't think 110 or the Knots implementation had replay protection.)

Understood. I'm not asking BIP-110 to implement replay protection. If replay protection is considered out of scope, then BIP-110 should explicitly document that it does not provide replay protection and that chain-split/coin-splitting risks are outside its scope.

Where is the appropriate place to document these risks before BIP-110 is deployed?

@TheBlueMatt I'm not opposed to updating BIP3. In this case, 110 was deployed; the criteria "an established project having deployed support for the BIP in mainnet software releases" is fulfilled. The following step would be to move it from deployed to closed

Why does it need to move through deployed to closed? The flowchart in BIP 3 does not mandate such a move, and it is clearly not deployed in a meaningful sense. BIP 3 is explicit - "a BIP may be advanced to Deployed upon request by any community member with evidence8 that the BIP is in active use".

This is clearly not true in the context of a proposed soft fork. In the context of some wallet standard citing the "established project having deployed support for the BIP in mainnet software releases" suggested possible evidence makes sense, but not in the context of a soft fork. The same sentence goes on to suggest an alternative criteria for a soft fork - "a soft fork proposal’s activation criteria having been met on the network, or rough consensus for the BIP having been demonstrated". Both of these are demonstrably untrue for BIP 110.

and not to remove it as you suggested in https://x.com/TheBlueMatt/status/2086218120998568098.

One could very reasonably argue that BIP 110 now describes not Bitcoin but 110-coin - it is a distinct chain, with a token which is not freely tradable (with Bitcoin), but there do exist distinct credit and debits on 110-coin, if nothing else OCEAN has a separate sharechain for it. That would make BIP 110 off-topic as it no longer relates to Bitcoin.

Why does it need to move through deployed to closed?

It can be moved from complete to closed if the author does it: "BIPs with Complete status may be moved to Closed per the authors' announcement to the mail list."

One could very reasonably argue that BIP 110 now describes not Bitcoin but 110-coin

I think the scope criteria relates to initial acceptance of a BIP draft and that the idea, and intent of BIP 3, is to retain closed BIPs as a record for historical/educational interest.

It can be moved from complete to closed if the author does it: "BIPs with Complete status may be moved to Closed per the authors' announcement to the mail list."

Sure, my point is it should be marked Closed today. It clearly does not qualify at all as Deployed.

I think the scope criteria relates to initial acceptance of a BIP draft and that the idea, and intent of BIP 3, is to retain closed BIPs as a record for historical/educational interest.

Then it should be marked Closed, which exists to store BIPs of historical interest.

it should be marked Closed

Yes, if the BIP author takes the initiative. @dathonohm?

I think moving this through Deployed is acceptable, just add another commit to move it to Closed as well after that.

I think moving this through Deployed is acceptable, just add another commit to move it to Closed as well after that.

If BIP-110 is considered Deployed because Knots has shipped support, does that status refer to software deployment rather than activation of the consensus rules on the Bitcoin network?

I think moving this through Deployed is acceptable, just add another commit to move it to Closed as well after that. @murchandamus Done, sending a mail list post for the update to closed. Edit: published at https://groups.google.com/g/bitcoindev/c/b_aV3JUtUqg/m/HwFbYFJwCAAJ

I also think the intermediate "Deployed" commit deflates the value of that concept.

a soft fork proposal’s activation criteria having been met on the network

I would interpret this as:

• completing a full signaling period, crossing the threshold; and
• reaching ACTIVE status; and
• on the majority chain

Not one of these criteria has been met, the first two are estimated to take decades at the current pace, and the third criteria is near impossible.

BIP110 doesn't contain a natural date to consider it failed:

• its activation deadline is based on height, instead of time (BIP 9), so it may never be reached
• its mandatory signaling makes rejection impossible by its own internal logic

I've asked on the mailing to provide an alternative set of failure criteria, but so far received only sophistry.

(so I suggest going straight to Close)

I'm similarly confused by the intermediary Deployed state - there is nothing in BIP 3 that seems to imply BIP 110 has reached the Deployed state to me.

@Sjors @TheBlueMatt What course of action are you proposing? I currently see three:

• Complete -> Deployed (per the first example criteria given in BIP 3) -> Closed (after four weeks without valid objection)
• Complete -> Closed per the authors' announcement to the mail list (not in our hands)
• Disregard BIP 3 and move it directly to closed

Just move it to closed as @Sjors says.

Or replace it with asciiart of a dickbutt, or any other action which would make it clear that is no longer a live proposal in the bitcoin system.

BIPs repo is emphatically not the governance of bitcoin, and LARPing as if it were through procedural theater is both distasteful and harmful to the movement. One does not need to fill out form 27b/6 to do the right thing, and one should not seek to do so if it gets in the way of doing the right thing, and particularly if it opens the door to disruption through procedural gamesmanship.

The project does not owe anyone any particular treatment, especially not for overtly hostile actors that smear contributors with regular vile accusations. And it particularly doesn't owe them any special coddling of their clear mental illness when it gets in the way of doing the right thing: which, in this case, is simply marking it closed, since both of its deployment avenues have clearly failed and its authors are off busily constructing an altcoin around it, so as a bitcoin proposal it is only of historical interest.

I am in favor of pragmatism, but skirting the process has risks. I'll let the other editors weigh in.

Straight to close has my preference. Timing wise doesn't really matter.

I think moving this through Deployed is acceptable, just add another commit to move it to Closed as well after that.

Reading the other responses here, I’m gonna change my position on this. While there was software running BIP110 on mainnet that criteria is the weakest form of evidence in the mentioned BIP3 section and meant to cover the deployment of a Specification BIP proposing a (non-consensus) application feature. A soft fork can be objectively evaluated based on the stronger evidence whether its activation criteria have been met. It seems obvious that BIP 110 should end up in the Closed status. Treating a failed activation attempt as a deployment for a soft fork proposal seems a bit weird. While a move from Complete to Closed is slightly unusual, it seems right here.

While BIP3 tries to provide guidance for the usual workflow and frequent situations we should expect, we shouldn’t tie ourselves in knots when there is an obvious pragmatic, broadly supported resolution that we could implement.

Beyond the abstract "close is obviously correct, making a big deal about slathering process on an obviously correct move as if people were entitled to a 'just' handling risks creating a misleading impression of controlling authority" issue, there a problem about documentation integrity too:

We have a state now where implementing this proposal now breaks your consensus with the bitcoin economy. This is not documented in the BIP, it's not even meaningfully disclosed as a risk (which probably should have been a merge blocker, especially given how many supporters are saying they didn't know that it would split the chain...), and its authors have wrongfully claimed that it wasn't a risk, and even now claim that it hasn't happened! -- and based on the authors handling of even the simple confusion over the additional P2A rule made it clear that there won't be any other resolution to this trap.

If it were a legitimately live proposal I could argue that the process isn't supposed to guarantee any particular quality bar-- a bip could literally even be coin stealing malware, I suppose-- but it's in fact a dead proposal and the fact that it's actually a broken one that fails to accurately disclose the rules and risks is a pretty good reason to act pragmatically and not muse about process entitlements and procedural mechanization even if you reject my concern that doing so is a "creation of perceived governance" risk.

The risk I was referring to was that of being accused of abuse of position.

Based on the feedback, I'll swing by in an hour or two with the idea to update directly to close.

There isn't a single block height, looking at the heaviest chain today, where any of the rules of this BIP was enforced. Even the mandatory signalling rules were never enforced in the heaviest chain

Therefore it was never Deployed at any time.

PS: i.e. the activation criteria were never met:

[BIP3 on Deployment] ... a soft fork proposal’s activation criteria having been met on the network

If replay protection is intentionally out of scope for BIP-110, where is the authoritative documentation of the resulting chain-split/replay risks and their operational mitigations? If this belongs outside the BIP, what is the intended scope/owner for documenting those deployment risks?

The risk I was referring to was that of being accused of abuse of position.

Right. My concern is that being clearly worried about that sends a signal to the public that you (/editors generally) have a position of authority over Bitcoin which carries particular duties to act on behalf of others. I think this is dangerous since perception of authority is what creates the actuality of it, particularly in Bitcoin where many are confused by the lack of hierarchical governance and try to project a governance role onto random functions. A statutory bips repository would be a highly undesirable risk for the ecosystem and an easy target for various attacks.

The BIPs repo is a documentation repository, a technical manual, the repo is descriptive not prescriptive (even though the documents themselves instruct conformance-- but specs can be found anywhere, and behavior can exist without any spec at all). While there should be pride in quality of the collection and its management-- which includes managing it as a resource for public use and not just an editors personal interest (though the idea that any of the people commenting so far have some kind of personal conflict of interest in this case is pretty bizarre). But this is no different than making any other quality reference work.

To that extent my quip about dickbutting the document, while partially in jest, was only partially because doing something like that would demonstrate that This Is Not The Governance Your Looking For to anyone who was confused, and this would be of considerable value. If the editors would find such user-harmless shenanigans (rarely) entertaining and helpful to morale they should absolutely do it!

It can be a fine line for sure, everyone wants to be proud of making a good technical resource. But that's all it should be. A technical resource is better if it's inclusive in various ways, opinionated in various ways, etc. But in a fair governance system there is entitlement to representation that should not exist here. BIPs repo is tends to be inclusive and generally neutral makes for a better resource and because it lowers editorial costs-- but when it doesn't make for a better resource and doesn't lower costs (e.g. because playing neutral invites endless criticism over being neutral enough) then you shouldn't do it, because these values should not themselves be terminal goals.

And in this case being an excellent technical resource really demands marking this document as closed, or at least adding a note that it will isolate implementations from consensus or similar. ... it probably will also cause the authors and their supporters to make hyperbolic allegations (because literally anything that isn't doing what they say has reliably done so...). To the extent that it matters at all I think that's actually useful, not because I want to cause them any harm (not that closing this does so!) -- but because the complaint obnoxious as it may be is an opportunity to educate.

There is probably nothing sensible that can be done that will appease the authors and avoid hyperbolic criticism, because their demands are just not sensible right now, in spite of the considerable effort you and others put into trying to help them better argue their own points. If you're worried about being personally attacked on it feel free to attribute the decision to me. :P

As the feedback has been to move directly to Closed due to BIP 3 being in-adapted to this particular edge case context, discussion on deployed seems moot now. Even before that, passing via deployed was primarily about respecting BIP 3, I think.

If replay protection is intentionally out of scope for BIP-110, where is the authoritative documentation of the resulting chain-split/replay risks and their operational mitigations? If this belongs outside the BIP, what is the intended scope/owner for documenting those deployment risks? @avra911 Perhaps you are confused or I am. I don't know who said that.

@avra911 Perhaps you are confused or I am. I don't know who said that.

Thanks. My question is specifically about the chain-split/replay risks and operational mitigations that, as you said, the BIP-110 author/champion should have documented before deployment. Where is that authoritative documentation? If it was intended to be part of BIP-110, it appears to be missing; if it was intended to live elsewhere, where should it live and who owns that documentation?

I think that question remains unanswered by the clarification above.

There is probably nothing sensible that can be done that will appease the authors and avoid hyperbolic criticism, because their demands are just not sensible right now, in spite of the considerable effort you and others put into trying to help them better argue their own points. If you're worried about being personally attacked on it feel free to attribute the decision to me. :P @gmaxwell Got it :p. We're of course all weary of the sea-lioning and obstructive behavior of 110's proponents, and I'm no fan of process for process' sake. I prefer getting things done. Updating this pull now.

Updated, including the pull title and description.

ACK

@avra911: If BIP110 had been successful, it wouldn’t have needed replay protection. If they now proceed to create an altcoin that is a separate endeavor than BIP110 and not on-topic here. So either way, I have no idea why you are bringing up replay protection here multiple times already.

@avra911: If BIP110 had been successful, it wouldn’t have needed replay protection. If they now proceed to create an altcoin that is a separate endeavor than BIP110 and not on-topic here. So either way, I have no idea why you are bringing up replay protection here multiple times already.

Fair enough. I understand now that this is considered outside the scope of this BIP discussion. My concern remains that, because BIP-110 would be deployed on a network with pre-existing UTXOs and users, a chain split could result in UTXO/transaction divergence and associated operational security risks. I would expect those risks and their mitigations to be explicitly documented somewhere before deployment. I have not been able to find that documentation, so I will leave it there. Thanks!