MINER EDUCATION · BIP110 / RDTS SOFT FORK
MINER EDUCATION SERIES
This document explains what BIP110 is, what the realistic scenarios look like for miners, and exactly how you could respond — so you can make informed decisions with your hashrate.
“MANDATORY” SIGNALING BLOCK 961,632 (~Aug 2026) | EARLY LOCK-IN THRESHOLD 55% per retarget period | DURATION IF ACTIVATED ~1 year (52,416 blocks) | CURRENT MINER SIGNALING ~0.6% (as of this writing) |
SECTION 01
A soft fork is a backward-compatible tightening of Bitcoin's consensus rules. Nodes enforcing the new rules reject certain blocks that would have been valid under old rules; nodes running older software still accept everything that enforcing nodes accept. This asymmetry is what creates the risk of chain splits during contested activations.
Bitcoin has no singular authority. Miners produce blocks, but which blocks are accepted — and therefore which chain represents "Bitcoin" — is determined by the nodes and users that make up the network. Miners work for the network: a miner whose block is rejected by the network earns nothing on that block, regardless of how much hashrate went into it. This is not a new dynamic; it is the foundational governance model Bitcoin has always operated under.
It is also why OCEAN is committed to giving miners as much agency as possible through tools like DATUM — and why this document exists. Informed miners can make their own decisions. Uninformed miners are at the mercy of whoever controls their block template.
Method | HOW IT WORKS |
MASF(Miner-Activated) | Miners signal readiness via version bits. Once a threshold is reached within a single 2,016-block difficulty adjustment period, the changes lock in. Miners have direct agency over when activation happens. Traditional miner-activated soft forks required 90–95% signaling. BIP110 uses 55%. |
UASF(User-Activated) | Enforcing nodes impose the new rules at a predetermined block height, regardless of miner signaling. Effective only if a meaningful portion of the economic network is running enforcing software. BIP110 includes a mandatory signaling window where enforcing nodes reject non-signaling blocks, ensuring activation by a specific height if and only if miners fail to act. |
A CRITICAL DISTINCTION |
BIP110's 'mandatory' activation is mandatory only to nodes that have chosen to enforce BIP110. If the broader network - miners and the economic nodes they serve - does not adopt it, BIP110-enforcing nodes are the ones on the minority side, and their chain stalls for lack of hashrate. 'Mandatory signaling' is the mechanism by which enforcing nodes guarantee lock-in on their chain. Whether that chain becomes the accepted “Bitcoin” network is a separate question, determined by network-wide economics. |
If a meaningful fraction of nodes enforce BIP110 and activation occurs while a meaningful fraction of miners are not producing BIP110-signaling blocks, the network may diverge into two chains. The resolution depends on which chain accumulates more hashrate — and which chain the broader Bitcoin economy and its participants continue to use.
One specific asymmetry worth understanding: non-enforcing (older) nodes will follow whichever chain is longest, including a BIP110 chain if it accumulates more proof-of-work. BIP110-enforcing nodes will only follow the BIP110 chain, regardless of the length of any other chain. This means outcomes are not symmetric — the behavior of enforcing nodes is strictly bounded, while non-enforcing nodes are permissive.
THE CORE MINER RISK |
A miner whose block is rejected by the network of nodes earns nothing — no reward, no fees. Whether this happens due to a chain split or a block not signaling during the mandatory window: the outcome is wasted work. The goal of preparation is to ensure your hashrate is contributing to valid blocks before that moment, not scrambling to respond after. |
SegWit (2017) is the most frequently cited precedent for a contested soft fork activation. The comparison is partial at best. SegWit had 20-30% miner signaling for many months before ultimately activating through MASF, with a UASF deadline providing pressure. BIP110, with fewer than 25 days until the “mandatory”signaling window as of this writing, is sitting at effectively ~0% miner signaling. The dynamics are sufficiently different that direct analogies should be treated with caution.
SECTION 02
BIP110 and RDTS (Reduced Data Temporary Softfork) are the same proposal — BIP110 is its formally assigned number; RDTS is its formal name. The proposal was authored by Dathon Ohm. It is a temporary, one-year soft fork that imposes consensus-level restrictions on certain data fields in Bitcoin transactions, with the stated aim of limiting arbitrary data embedding. All known monetary uses of Bitcoin are intended to remain unaffected.
This document does not argue for or against BIP110. That debate is active and contested within the Bitcoin community. For the full technical specification, the proposal is documented at bip110.org — written by BIP110 proponents; not affiliated with or endorsed by the author of this document.
December 1, 2025
Signaling window opens
Miners may begin signaling readiness using version bit 4. A 55% threshold in any single 2,016-block retarget period triggers early lock-in (MASF activation). As of this writing, 59 total BIP110-signaling blocks have been mined — nearly all by OCEAN miners using DATUM to construct their own block templates.
Now → ~August 2026
MASF window [YOU ARE HERE]
Activation via MASF remains possible if any retarget period reaches 55% signaling. As of this writing, no major mining pool has committed to signaling. F2Pool co-founder Chun Wang publicly stated (February 19, 2026) that F2Pool will not signal BIP110. Public block signaling trackers exist online. Miners should monitor for announcements from other major pools, as conditions can shift quickly within a single retarget period. While miners can react when the mandatory signaling window opens, doing so involves real risk. Miners should form a plan and configure their nodes in advance.
~August 2026 · blocks 961,632–963,647
“Mandatory” signaling window [LATEST FORK POINT FOR MINERS]
BIP110-enforcing nodes begin rejecting blocks that do not signal for RDTS. For miners, this window is the latest possible effective fork point: blocks not signaling are rejected by enforcing nodes, and the two chains diverge from here if meaningful hashrate is on each side. Whether this causes network disruption depends on what fraction of the economic network is running enforcing software at this point.
~September 1, 2026 · block 965,664
Unconditional activation on enforcing nodes
BIP110 consensus rules take full effect on all enforcing nodes. Blocks containing transactions that violate RDTS rules are rejected by those nodes from this point. What happens next depends entirely on which scenario plays out — covered in Section 03.
~September 2027
Auto-expiry
The deployment expires after approximately 52,416 blocks unless extended. Rules revert to pre-RDTS state absent a new accepted fork proposal.
This is practically important for most OCEAN miners. Bitcoin Knots — the node implementation maintained by Luke Dashjr and used by the majority of OCEAN and DATUM miners — has enabled RDTS enforcement in its latest version. If you upgraded to the current main Knots release, your node is enforcing BIP110.
To run Knots without enforcing RDTS, you must either stay on a pre-RDTS version, or deliberately install the alternative build (29.3.knots20260507) available at bitcoinknots.org — this build is not the primary release, requires deliberate selection, and may not be available easily on all platforms.
Bitcoin Core, which does not include BIP110 support, is also an option, but not generally recommended. DATUM is agnostic to the template generator, and is fully compatible with Bitcoin Core as a template source.
Software | RDTS ENFORCEMENT STATUS |
Bitcoin Knotsv29.3.knots20260508 (or higher) | Enforces RDTS. This is the main Knots release. If you upgraded recently, you are enforcing RDTS. |
Bitcoin Knotsv29.3.knots20260507 (or earlier) | Does not enforce RDTS. A distinct build available separately at bitcoinknots.org. Not the primary release. Running it requires deliberate selection and download. |
Bitcoin Core (all current releases) | Does not enforce RDTS. Bitcoin Core does not include BIP110 support as of current releases. This may change if BIP110 achieves overwhelming network adoption, but that is not the current situation. Core also offers less fine-grained template control than Knots, which is potentially relevant for DATUM miners. |
SECTION 03
The outcome of BIP110 is not predetermined. No matter what anyone tells you, BIP110 has not already won. It doesn’t already have consensus. It is not a required upgrade. Etc.
Miners should think through the range of scenarios rather than planning only for a single outcome. The three most realistic paths diverge significantly in their implications for your hashrate and rewards.
Scenario A — BIP110 fails to gain support; enforcing nodes stall [NO NETWORK DISRUPTION] |
Miner signaling remains near zero through the mandatory window. The BIP110 chain, with only a small fraction of hashrate, cannot build a viable competing chain. Enforcing nodes stall or fall irreversibly behind the main chain. |
For miners not signaling: No disruption. The Bitcoin network continues as it does today. |
For miners enforcing RDTS: If your node refuses to build on or accept non-RDTS blocks, you may find yourself attempting to mine on a chain with no meaningful hashrate — your blocks earn nothing because no viable chain really exists for you to extend. This is the risk of being on the minority side of a failed activation. Miners should track network-wide milestones carefully. DATUM miners are responsible for their own node configuration. |
Given current signaling levels, substantial change would be needed before this ceases to be the most immediately plausible path — but miners should not assume certainty in any direction. |
Scenario B — BIP110 gains sufficient support and activates [SMOOTH TRANSITION] |
BIP110 reaches the 55% threshold in a retarget period (MASF), or enough of the network enforces during the mandatory window that the BIP110 chain becomes dominant and the rest of the network follows. |
For miners already signaling: No disruption. Your blocks are valid on the dominant chain and you continue earning rewards normally. |
For miners not yet signaling at that point: Your blocks are rejected by the majority of the network during the mandatory signaling window. You earn nothing on rejected blocks. Switching your signaling posture quickly limits ongoing losses, but does not recover rewards from already-rejected blocks. The earlier you act, the less exposure. |
Miners can only earn rewards by mining on the RDTS chain in this scenario. |
Scenario C — Contested split; meaningful support on both sides [HIGHEST UNCERTAINTY] |
A significant fraction of miner hashrate (say, 30%+) signals and enforces RDTS entering the mandatory window, while a meaningful fraction does not. Two chains diverge from the fork point. |
For all miners: This scenario carries the most uncertainty and the highest potential exposure. Block rewards on whichever chain loses out may ultimately carry little value. |
Signaling matters: After the fork point, blocks not signaling for RDTS are rejected by RDTS-UASF enforcing nodes during the mandatory window. Your signaling must be consistent with the chain you are mining. DATUM miners must ensure their node configuration matches their intent. |
Chain split dynamics: The RDTS chain can orphan blocks from the legacy chain if it accumulates enough proof-of-work to overtake it — and because non-enforcing nodes follow the longest chain, a sufficiently dominant RDTS chain would pull legacy nodes along with it. The legacy chain cannot orphan RDTS blocks from the RDTS chain's perspective. However, if RDTS hashrate is insufficient to dominate, the RDTS chain itself may still stall due to an unfavorable difficulty-to-hashrate ratio — its own form of failure. |
How chain splits resolve: Through hashrate distribution, infrastructure adoption, and the decisions of economic participants broadly — exchange listings can play a role, but they are not the sole determinant. The chain with sustained hashrate and continued use is the one that remains practical. This process creates real uncertainty that takes time to resolve. |
Given current signaling levels, reaching 30%+ support before the mandatory window requires a rapid and substantial change in miner behavior. That is not impossible, but the current data provides no basis to assume it. |
BIP110's 55% MASF threshold is evaluated per retarget period, not as a cumulative running total. A single retarget period is approximately two weeks. If a large portion of hashrate begins signaling rapidly, MASF lock-in can happen within one period with essentially no warning. Miners who have not made a decision in advance are making one by default. Do not wait for the mandatory window to form a plan.
Overall uncertainty
There are many paths in between the outlined scenarios, as well as scenarios no one can predict. It's a miner’s responsibility to remain vigilant with regard to soft fork activations.
Author’s Two Sats
Scenario A is the most likely scenario based on all measurable metrics available at this time.
SECTION 04
Redacted/No longer applicable.
SECTION 05
DATUM is OCEAN's mechanism for returning block template sovereignty to individual miners. Through DATUM, you run your own Bitcoin full node, you select which transactions go into your blocks, and you decide how your blocks are configured — including whether they signal for BIP110. OCEAN provides the pooled reward infrastructure; you provide the intelligence.
You do not have to follow whatever OCEAN's default template does. You have a choice.
You have direct control and direct responsibility. The template your node generates is the template that gets mined. Your node's configuration governs your blocks — and you are responsible for keeping that configuration aligned with the Bitcoin network.
Your node | WHAT IT MEANS IN PRACTICE |
Knots 20260508 (or higher) (enforcing RDTS) | Your templates are built with RDTS rules applied. Your blocks signal for RDTS. If BIP110 activates on the dominant chain (Scenario B), you are positioned without further action. If it fails (Scenario A), your node may be building on a stalling chain. Monitor milestones and be prepared to reconfigure independently if needed. |
Knots 20260507 (not enforcing RDTS) | Your templates are built without RDTS signalling. If BIP110 activates on the dominant chain (Scenario B), your work will no longer earn useful rewards until you reconfigure. This requires deliberate action: downloading the non-primary Knots build from bitcoinknots.org is the path back if you have moved to the primary release. |
Bitcoin Core (not enforcing RDTS) | Does not enforce RDTS as of current releases. Functionally similar to non-enforcing Knots above for this purpose. Core provides less granular template control than Knots, which reduces some of the decentralization benefits of running DATUM. May change in future Core releases if BIP110 achieves broad adoption, but that is not the current situation. |
The key action window is the retarget period immediately before the mandatory signaling block. Changing your node configuration before that period begins gives you a full two weeks of buffer. Changing it during the mandatory window under time pressure could be a significant source of error.
☐ Know what you're running now. Running Knots 20260508 (or higher)? You are enforcing RDTS. Know your current position before the mandatory window approaches.
☐ Monitor network-wide hashrate signaling. Public block signaling trackers exist online. Watch for any retarget period approaching the 35–55% range, which could trigger enforcement milestones.
☐ Watch for announcements from other major pools. A large pool announcing intent to signal could shift cumulative network hashrate within a single retarget period. No pool has committed to signaling as of this writing; F2Pool has publicly stated it will not. But this can change quickly.
☐ Have a plan for each scenario before block 961,632. Know what you will do if Scenario A, B, or C materializes. DATUM miners are responsible for their own plan and for staying aligned with the network.
☐ Follow pool communications. Pools will likely communicate if things change significantly. Follow direction from your pool as needed to protect your revenue.
REFERENCE
https://wickedsmartbitcoin.com/bip110_signaling
https://redblocks.supertestnet.org/
https://luke.dashjr.org/programs/bitcoin/files/charts/services.html
https://thebitcoinportal.com/live/nodes/bip110
https://mainnet.observer/charts/blocks-bip110-signaling/
BIP110 / RDTS
The same proposal. BIP110 is its formally assigned number; RDTS (Reduced Data Temporary Softfork) is its informal name. A consensus-level soft fork that temporarily restricts certain data fields in Bitcoin transactions. Authored December 2025 by Dathon Ohm. Unconditional activation on enforcing nodes at block 965,664 (~September 2026). Deployment duration: ~1 year (52,416 blocks).
Soft fork
A backward-compatible tightening of Bitcoin's consensus rules. Blocks that pass the new rules are accepted by all nodes. Blocks that violate the new rules are rejected by enforcing nodes but still accepted by non-enforcing nodes. Miners whose blocks are rejected by the dominant network chain receive no reward for those blocks.
MASF
Miner-Activated Soft Fork. Activation triggered when miners signal readiness and a threshold is reached within a single 2,016-block difficulty adjustment period. For BIP110, the MASF threshold is 55% of blocks in one period. Not a cumulative running total — each retarget period is evaluated independently.
Mandatory signaling window
Blocks 961,632–963,647. During this window, BIP110-enforcing nodes reject blocks that do not signal bit 4, guaranteeing lock-in on the BIP110 chain for those nodes. For miners, this is the effective fork point. Whether it causes network disruption depends on how much of the broader network is running enforcing software.
Bit 4
The version bit miners set in block headers to signal readiness for BIP110.
Retarget period
A 2,016-block window (~two weeks) after which Bitcoin adjusts difficulty. BIP110's signaling thresholds are evaluated per retarget period, not cumulatively across the deployment window.
Chain split
A divergence in the blockchain where two groups of nodes maintain incompatible chains after a fork activation point. Miners on the minority chain risk earning rewards that are economically worthless if that chain is not adopted by the broader network.
DATUM
Decentralized Alternative Templates for Universal Mining. OCEAN's open-source protocol allows individual miners to construct their own block templates using a locally-run Bitcoin full node, while still participating in OCEAN's pooled reward structure. With DATUM, the miner — not the pool — decides what goes into blocks. 2026-07 Note: DATUM work will be attributed only to the chain the miner is enforcing.
Bitcoin Knots
A Bitcoin node implementation maintained by Luke Dashjr with more granular template control options than Bitcoin Core. The majority of OCEAN and DATUM miners run Knots. The current primary release (v29.3.knots20260508) enforces RDTS. A non-RDTS build (v29.3.knots20260507) is available separately at bitcoinknots.org.
This document is produced by Jason Hughes (wk057) for miner education purposes. It does not constitute financial or legal advice. Mining decisions carry financial risk. Information reflects the state of BIP110 as of July 2026 and may or may not be updated as the situation evolves. The link to bip110.org is provided for technical reference only and is not affiliated with or endorsed by Hughes.
This document is not produced nor endorsed by OCEAN.