Navigating the BIP‑110 (RDTS) Activation

A decision guide for Bitcoin node operators, Lightning users, and merchants.

Read this first. This is educational material about protocol mechanics, published 5 August 2026. It is not financial, legal, or tax advice, and it is not a prediction. Statements of fact reflect the publication date; the consensus parameters are stated so you can verify every one against your own node (Appendix). Your node, your keys, and your decisions are your own — Start9 publishes this to inform them, not to make them for you.

Contents

1. What is happening, and when
2. Doing nothing can carry risk
3. TLDR: the safe option, and the only one that forfeits nothing
4. The scenarios at a glance
5. How a divergence resolves
6. Who ends up on which chain
7. Why a split is dangerous: replay
8. Why a split is dangerous: Lightning
9. Decision tree — before mandatory signaling
10. Decision tree — did it actually split?
11. Decision tree — after a confirmed split
12. Doing it on StartOS
13. What not to do

• Appendix: verifying the parameters yourself

1. What is happening, and when

At block 961,632 (~8–9 August 2026), BIP‑110 — the Reduced Data Temporary Softfork (RDTS) — enters mandatory signaling. It is a consensus change enforced by recent Bitcoin Knots releases, deployed as a version‑bits soft fork under the deployment name reduced_data and signaled by bit 4 in the block header's version field. From that block, an RDTS‑enforcing node rejects any block that does not set bit 4. If miners put a non‑signaling block on the heaviest chain, the network splits in two.

Start9 packages Bitcoin Core, Bitcoin Knots (pre‑RDTS), and Bitcoin Knots (RDTS). This guide takes no position on which chain you should follow. That is a choice about consensus rules, and it is yours.

These heights come from the consensus parameters of the Knots release Start9 ships (v29.3.knots20260508) and are what the StartOS package itself uses as its re‑validation anchor. Verify against your own node with getdeploymentinfo — look for the reduced_data deployment.

Miners decide whether there is a split

The outcome is entirely in miners' hands:

• If every block in the window on the heaviest chain signals bit 4, there is no split. RDTS activates, one chain continues, and nothing below matters.
• If the heaviest chain contains a non-signaling block within the window, enforcing nodes reject it; everyone else accepts it. From that moment the two populations are looking at different tips.

2. Doing nothing can carry risk

Some failure modes here take your money whether or not you picked "correctly" -- and whether or not you do anything at all. An open Lightning channel is mirrored onto every chain, and your node can police only one of them (§8). A transaction broadcast on one chain spends your coins on all of them (§7). And if a hard fork follows the split, an open channel does not merely expose your balance on that chain -- it can strand it permanently (§8). These risks attach to inaction as much as to action.

3. TLDR: the safe option, and the only one that forfeits nothing

If you do not want to engage with any of this:

1. Close your Lightning channels today, leaving time for the closes to confirm well before block 961,632. Broadcasting is not closing -- see How much lead time do you need.
2. Withdraw coins from exchanges to self-custody now. Coins on an exchange at the split are the exchange's coins on every chain, credited back to you under rules no one has announced (§9).
3. Then stop transacting -- send nothing, sweep nothing, accept nothing -- until the outcome is clear (§10).

Self-custodied, confirmed-closed, and idle, your coins exist identically on every chain, nothing can be replayed against you, and no split outcome can take them from you. Every other decision can be made later, calmly. This holds whatever client you run: chain choice is a preference; an open channel across a split is a liability on every side of it.

And closing is not only the safe option -- it is the only one that forfeits nothing. You already own your balance on every chain a split produces; an open Lightning channel is the one thing that can cost you it there (§8).

4. The scenarios at a glance

Only the first is a non-event. Every block in the window signals, RDTS activates on a single chain, and the day passes as an ordinary day in Bitcoin. If that is what happens, you closed your channels for nothing, and the only residue is that after activation a non-RDTS node's mempool will accept transactions that cannot confirm under the new rules, so 0-conf becomes unreliable.

Every other scenario carries real risk. In one, nothing splits but the enforcing nodes freeze in place -- quiet for everyone else, dangerous for whoever is running them. In all the rest, the chain splits -- immediately, or later by way of a hard fork -- and a split is what produces all of it: coins that exist on two or three ledgers at once, transactions that spend on all of them, Lightning channels mirrored onto chains you cannot watch, and a client you may have to choose between. That is what the rest of this page is for. None of it is a prediction that a split will happen -- it is a recommendation for what to do now in case one does.

This section does not rank these scenarios by likelihood -- that judgement needs the analysis in §5, which lays out the incentives. It is up to you which are likely enough to consider. "Running RDTS" means Bitcoin Knots (RDTS). Core and Knots (pre-RDTS) are consensus-identical and non-enforcing (§6).

No chain split: RDTS wins on hash rate immediately

No chain split: RDTS stalls completely, abandoned

The enforcing nodes hit block 961,632, see no compliant blocks, and simply stop advancing -- frozen in time while the rest of the network moves on.

This is the one path on which the RDTS ledger simply ends, and it requires the announced hard-fork client never to ship. If it does ship, a stall is not an ending but its trigger, and this scenario becomes Chain split: RDTS stalls completely, hard-fork client released -- where non-enforcing nodes stop being bystanders.

Non-enforcing nodes: no risk -- on this path only, and only for as long as it holds.

Temporary chain split (reorg): RDTS catches up in hash rate after mandatory signaling begins

If enforcing miners gain the upper hand after the split begins, non-enforcing nodes will eventually abandon their branch and jump to the RDTS chain -- rewriting recent history in the process (a "reorg").

Chain split: RDTS stalls completely, hard-fork client released

Chain split: RDTS survives as a slow minority chain, hard forks later

Same ending as above, but Chain B keeps producing blocks the whole time -- slowly, because it inherits a difficulty setting sized for the whole network's mining power -- and Chain A never absorbs it back. Everything that was "deferred" in the stall scenario happens live here instead.

Chain split: RDTS survives as a slow minority chain, no hard fork

The previous scenario minus the relaunch: both chains just... continue, indefinitely, while Chain B slowly grinds its difficulty back down to match its mining power (§5). Every risk from the previous scenario that doesn't involve Chain C still applies. What changes:

5. How a divergence resolves

Whether a non‑signaling block becomes a lasting split — and how slowly the RDTS chain moves if it does — comes down to miner incentives and to the difficulty that chain inherits. This is the analysis the scenarios above are weighed against.

A lasting soft‑fork split is unlikely — which is not necessarily reassuring

Divergence is not the same as two chains coexisting. A soft-fork split is unstable, and the instability works differently for nodes than for miners. At the node level, one mechanism runs in a single direction:

Non-enforcing nodes accept every block enforcing nodes accept, plus the ones they reject. So a non-enforcing node will reorganize onto the RDTS chain the moment that chain has more work, and a non-enforcing miner has no way to refuse, because it is their own software that performs the reorg. Enforcing nodes cannot be dragged the other way: they reject the non-signaling branch outright.

For miners the picture is different. Once the first non-signaling block exists, no miner can stay neutral, and signaling stops being the choice that matters:

• Chain membership is inherited from the parent, not the version bit. A block that signals bit 4 but extends a non-signaling ancestor is exactly as invalid to enforcing nodes as that ancestor. After the fork point the real decision is which tip to extend, and every block a miner produces commits its full subsidy and fees to one side. There is no hedge.
• Rational miners follow hash rate, not the current work lead. The branch with the larger share of ongoing hashrate ends up with the most accumulated work regardless of who is ahead today, so a miner deciding where to point hardware is really forecasting where other miners will point theirs. A heavier chain that is being out-mined is not a safe chain; it is a chain that is losing.
• Both sides are exposed; only the failure mode differs. A miner extending the non-enforcing branch risks the one-way reorg: if the RDTS branch takes the work lead, their own software orphans every block they have mined since the fork point, subsidy and fees included, with no defensive move available. A miner extending the enforcing branch can never be reorged off it, but if that branch stays the minority they are burning real hashrate on a slow minority ledger whose coins the economic majority may not recognize. Immunity to reorg is not immunity to loss.

The divergence therefore resolves toward whichever side commands the hashrate, and quickly, because standing on the losing side is expensive for the miners standing there. The realistic outcomes are not "two chains coexist for months":

1. Enforcing hashrate falls well short of the legacy chain's. This covers everything from negligible to substantial: as long as the RDTS branch is not on a path to take the work lead, the reorg threat never fires, no matter how "meaningful" the minority is in absolute terms. What varies is only how slowly the RDTS chain moves — from a dead stall at inherited difficulty (see below) to a limping minority chain — and miner economics push it downward from there, since its blocks pay in coins the majority may not recognize. The only way that ledger becomes usable again is the hard‑fork client, with its new proof of work and difficulty reset. The durable split, if there is one, is between the original chain and that hard fork — not between the two soft‑fork chains.
2. Enforcing hashrate is close to matched, or above. Only here does the one‑way reorg dominate, and near parity it biases toward RDTS, because the two branches do not need the same thing: the RDTS branch needs the work lead once, while the legacy branch must hold it continuously. One stretch of block luck or one modest defection trips the ratchet; miners on the non-enforcing branch cut their losses and extend the RDTS tip — their own nodes will do it for them the moment that tip leads on work — and the divergence closes.

Neither outcome removes the Lightning exposure, which is why this guide exists:

• Outcome 1 leaves every channel that was open at the divergence mirrored onto a frozen or barely‑moving ledger — one that the hard‑fork client is explicitly designed to revive, and on which a slow trickle of blocks means revoked states can still confirm. See §8.
• Outcome 2 resolves by non‑enforcing nodes reorganizing onto the RDTS chain, and that reorg can be deep. A reorg past a channel's funding depth can force‑close channels, and confirmations are unreliable throughout. See §12.

The difficulty trap

A minority chain inherits the full network's difficulty, and difficulty only retargets every 2,016 blocks. At reduced hashrate that retarget is very far away:

And one retarget is not enough: difficulty can fall at most 4× per period, so recovering from 1% of hashrate takes roughly four successive retargets — several years in total. This is the "stalled chain" scenario, and it would likely result in a new client that is a hard fork that changes the proof‑of‑work algorithm and adds a downward difficulty adjustment. It means a third chain, forking off the RDTS chain (because it had stalled), with different rules from both existing chains. Section 11 covers this in more detail.

6. Who ends up on which chain

The dividing line is RDTS enforcement, not Knots‑versus‑Core. This trips people up constantly:

Bitcoin Core and Bitcoin Knots (pre‑RDTS) are on the same chain. They have identical consensus rules. Knots differs in relay and mempool policy — what it will accept into its mempool and pass along — which is not a consensus rule and cannot split the chain. Running Knots without RDTS is a policy preference, not a chain choice.

And the fourth population, which is not a choice so much as an outcome:

Doing nothing is a decision. If you are running Knots with RDTS today and take no action, you will be on Chain B. If Chain B stalls, your node will keep running, keep showing peers, and keep reporting itself healthy — it will simply stop receiving blocks. Payments to you will never confirm. See §10 for how to detect this, because it does not look like a failure.

7. Why a split is dangerous: replay

Chains A and B have no replay protection

They share their entire history and UTXO set up to the block before the first non‑signaling one — anywhere from 961,631 to 963,646, since that block can fall anywhere in the window (§8). A transaction spending a pre‑split coin is a valid transaction on both. Nothing in it identifies which chain it was "meant" for.

Assume that anything you broadcast on one chain also spends your coins on the other. Anyone can copy a raw transaction from one network to the other, and during a contentious split people will.

The asymmetry you can exploit

RDTS is a soft fork, so its rules are stricter — but its two classes of rule arm at different heights, and the difference decides whether this technique works at all:

• From the split (the first non‑signaling block — 961,632 at the earliest): the only new rule is block‑level — enforcing nodes reject non‑signaling blocks. Every transaction remains valid on both chains.
• From activation (Chain B height 965,664 at the latest): the transaction‑level rules arrive — an output‑size limit and restrictions on certain script forms.

Only after activation does this one‑way relationship exist:

So, after activation, a transaction that deliberately breaks an RDTS rule can only ever confirm on Chain A. It only works in that direction: no choice of transaction rules can make a transaction Chain B–only, because RDTS only adds restrictions — every Chain B–valid transaction is by construction also Chain A–valid.

Do not plan around this technique. Activation is measured in each chain's own height, and Chain B climbs up to 4,032 blocks from split to activation at whatever rate its hashrate share allows. That span covers two difficulty retargets, so it is not simply 4,032 slow blocks: roughly six weeks in a matched split, ten weeks at 25%, eleven months at 5%. Per §5, a split is unlikely to survive anywhere near that long. During the period a split is actually likely to exist, RDTS imposes no transaction rules yet, and a rule‑violating transaction replays exactly like any other.

The direction-agnostic technique — and the only one available before activation — is to mix in an input that only exists on one chain, such as a coinbase output from a post-split block on that chain. That works in principle on either side. But:

You cannot split coins on a chain that is not producing blocks. If Chain B stalls, nothing confirms there at all: no splits, no sends, no sweeps. Your Chain B coins are simply frozen in whatever state they were in at the split.

Deferred replay is a real hazard

A transaction you broadcast on Chain A will propagate into Chain B's mempool. If Chain B is stalled, it sits there. Default mempool expiry is around two weeks — but anyone can rebroadcast, indefinitely. If Chain B later revives, those queued transactions become confirmable again, possibly in a different order, long after you stopped thinking about it. This matters most for Lightning (§8).

Chain C: expect replay protection, verify it anyway

A hard fork can include replay protection, and one this contentious very likely will. Do not assume it. Before moving any coin on Chain C, confirm:

• Replay protection exists and is mandatory, not opt‑in.
• It protects in both directions, not just C → A/B.
• Whether pre‑fork‑format transactions are still accepted, which would leave a replay path open.

8. Why a split is dangerous: Lightning

This is the part that loses people money, and it is worse than the on‑chain case.

The mechanism

1. Your channel exists on both chains. The funding transaction confirmed before the split, so both chains inherit it. Every commitment transaction you have ever signed is valid on both.
2. Lightning cannot tell the chains apart. A channel is identified by chain_hash, which is the genesis block hash — identical on both chains. Your node and a counterparty whose node follows the other chain will connect, gossip, route, and keep updating channel state as though nothing happened. Nothing in the protocol notices.
3. Your node watches exactly one chain — whichever your backing bitcoind follows. It is completely blind to the other one.
4. Therefore: your counterparty can broadcast a revoked commitment on the chain you are not watching. Your to_self_delay elapses with nobody objecting. They sweep. You never see it, and there is no recourse afterward — the justice window is gone.

This is symmetric — you could do the same to them — which means every open channel across the split is a mutual invitation. "My counterparty probably won't steal free money on a chain neither of us is watching" is not a security model.

Two more failure modes on top of that:

• In‑flight HTLCs at the moment of the split resolve independently on each chain. Block heights diverge, so CLTV deadlines diverge, and a payment can succeed on one chain and time out on the other.
• Force closes are not safe from fee spikes. Anchor channels rely on CPFP to fee‑bump the commitment transaction. On a congested minority chain, you need spendable UTXOs on that chain to bump with, and you are bidding against everyone else for very scarce block space.

Why watchtowers only solve half of it

You could point a watchtower at the other chain — running a second tower against a bitcoind that follows it. Both LND (wtclient) and Core Lightning (via the bundled rust‑teos plugin) support this, and both are packaged on StartOS. This needs a second machine. The three flavors share one bitcoind package id and data volume (§12), so a single StartOS server follows exactly one chain at a time — anything in this guide that asks you to watch both chains at once means a second server, a trusted friend's node, or an external block explorer. Given that, whether the tower actually works depends on the block production of the chain you are asking it to watch — not on which rules that chain enforces:

At current signaling the slow side would be the RDTS chain, but do not hard‑code that: the failure belongs to whichever side ends up short on hashrate. In a near‑matched split both sides are watchable in principle — though fee spikes make fixed‑fee justice transactions fragile everywhere.

Watching a minority chain is undermined by two compounding reasons:

1. Blocks are rare. At reduced hashrate with inherited difficulty, block space becomes extremely scarce while the mempool backs up. Fees on that chain can spike without bound.
2. Watchtower justice transactions are pre‑signed at a fixed feerate, and nothing can bump them. The tower holds an encrypted justice kit containing a transaction you signed when the state was created; it holds no key of yours and cannot re‑sign at a higher fee. CPFP is out too: a justice transaction has no anchor output, and in the altruistic mode shipping towers use (LND's wtclient, rust‑teos) the tower controls no output of it to spend a child from. The only party who could CPFP their own sweep output is you — on the chain you are by definition not watching. On a chain where scarce block space is being auctioned, a fixed‑fee justice transaction is likely dead on arrival, and raising it retroactively would mean re‑signing every state.

So: the party on the majority chain should not count on defending their minority‑chain balance. Run the tower anyway — it costs little, and it wins outright if that chain ever speeds up or the thief's own fee is low — but budget for it to fail and treat the balance as at risk, not as covered. And the party on the minority chain has a node that may not be able to confirm anything anyway.

The stalled chain does not make this go away — it postpones it

This is the argument that decides the whole question:

On a stalled chain, block height barely advances. Revocation and timeout windows are measured in blocks, so they barely advance either. The justice window on the stalled chain is still technically open months or years later — but by then essentially nobody is watching it.

And that ledger reviving is not a hypothetical — under outcome 1 it is the whole point of the hard‑fork client. Its new proof of work and difficulty reset exist precisely to make those blocks move again. When they do, every channel that was open at the divergence becomes broadcastable. Whoever is still paying attention when a stalled chain wakes up can steal from everyone who is not.

An open channel at the split is therefore not a risk that expires. It is an indefinite liability.

On Chain C the channel may become unrecoverable, not merely unsafe

Chain C is not a distant hypothetical. Under outcome 1 the hard‑fork client is the continuation of the RDTS ledger — reviving it is what the client is for. So the question is not whether Chain C matters to an open channel, but which of two replay‑protection designs it ships. Both are bad.

If old signatures remain valid on Chain C — replay protection that is opt‑in, or implemented somewhere other than the signature hash — then every revoked commitment you have ever signed becomes publishable there the moment Chain C starts producing blocks, against a channel nobody is watching. That is the theft scenario above, deferred and then handed to whoever is still paying attention.

If old signatures are invalid on Chain C — replay protection by changing the signature hash algorithm, the usual approach — then nobody can publish a revoked state and the theft window never opens. But the same stroke removes your exit:

• A unilateral close becomes impossible. Your commitment transaction carries your counterparty's signature, made under the old sighash. You hold it; you cannot re‑derive it, because that needs their key. The pre‑signed escape hatch that makes Lightning trust‑minimized is gone.
• A cooperative close survives only in principle. Both parties hold their own keys and could sign afresh, so the funds are not cryptographically lost. Realizing that needs your counterparty to still exist, still care about Chain C, and run patched software that signs with the fork's sighash — on both sides — plus agreement on the balance.
• There is no on‑chain fallback to negotiate against. The entire commitment‑and‑revocation machinery works by publishing a pre‑signed commitment. If none of them validate, neither party can establish any state unilaterally, and nothing makes the latest balance the binding one. A Chain C settlement is negotiation from scratch with no recourse behind it.

So "frozen" is the wrong word for this. A stalled chain thaws when blocks resume; this does not. It is an indefinite lock that opens only if one specific counterparty chooses to cooperate, through tooling that does not exist today. Pointing an existing Lightning node at a Chain C backend does not help — it would broadcast the same invalid commitment.

Contrast Chain B, which has no replay protection: there your pre‑signed commitment stays valid, so a unilateral close works whenever that chain produces blocks again, however slowly. The sighash change is precisely what converts eventually recoverable into recoverable only with permanent cooperation.

Both sides of the argument lose the same thing. To someone running RDTS, Chain C is the real Bitcoin, and a balance stranded in a channel there is simply their bitcoin, gone. To someone who rejects RDTS, it is a fork whose coins they never claimed. Different words, identical outcome: value that existed at the split and cannot be recovered.

It scales with the node. One channel is one stuck 2‑of‑2. A large routing node or LSP carrying thousands of high‑value channels through the fork would have to renegotiate every one of them individually, with mostly pseudonymous counterparties, most of whom will never answer. At that size the realistic outcome is that the Chain C balance is written off — for the node and for every counterparty on the other end of those channels.

You do not need to predict which design ships. One branch ends in theft, the other in a permanent lock. A close that confirms before the split avoids both, and it is the only thing that does. That is the entire argument for acting now instead of waiting to see what the client does.

If you do end up closing after the split rather than before it, back up your Lightning channel state first and keep it. Closing on one chain can leave your node with no record of a channel that is still open on the others — and that record is the only evidence of what you are owed there.

Which is why the answer is: close before the split

A cooperative close that confirms before block 961,632 is a plain 2‑of‑2 spend to two ordinary outputs. No timelocks, no revocation secrets, no watchtower, nothing to police. Every chain that descends from that block inherits it identically, forever. It is the only action that fully closes the exposure.

If you cannot cooperatively close — counterparty offline or unresponsive — force close now instead. Force‑closing on your latest state is safe: your counterparty holds no revocation secret for it, so there is nothing to punish. The commitment confirms pre‑split and is inherited by both chains, and the timelocked output is yours on each of them. If the delay elapses before 961,632, sweep it and you are completely clean.

Why a confirmed close survives a fork and an open channel does not

At the split you already own your balance on every chain that results. You do not have to claim it, register for it, or do anything at all — a chain that forks inherits the entire ledger, your coins included. That is the default, and it costs you nothing. A Lightning channel left open through a hard fork is the one way to lose it, and it comes down to who has to sign:

A signature you have not made yet cannot be invalidated by a rule change — you simply make it under the new rules. A signature someone else already made can be, and you cannot replace it. That single distinction is why an open channel risks your balance on a fork chain while a confirmed close carries it there intact.

This is loss prevention, not speculation. You are not betting that the fork chain will be worth something — you are declining to risk a balance you already hold on it, while nobody yet knows either way. Closing is not free: on‑chain fees, and for a routing node also reopening costs and foregone routing revenue while closed. But those costs are bounded and known in advance, and they are the most closing can cost you. What an open channel puts at risk is the balance itself. If the fork chains end up worthless, you paid the known cost and removed the theft risk; if they end up worth something, you still have what was already yours.

The one gap in the force‑close version: second‑stage HTLC transactions are pre‑signed by your counterparty, so an HTLC in flight when you force close can be stranded on a chain whose replay protection invalidates old signatures — the same mechanism, applied to a smaller amount. Stop routing and let HTLCs settle before you close, and the gap closes with them.

How much lead time do you need?

What protects you is the close transaction being confirmed before the chains diverge — not you having clicked "close."

A close still sitting in the mempool at the split is confirmed on neither chain, so neither inherits it as a settled close. It propagates into both mempools and confirms on Chain A. Then, if Chain B stalls, it never confirms there at all — mempools flush it after about two weeks, and Chain B is left with the funding output still unspent. At that point your position on Chain B is materially what it would have been if you had never closed: your counterparty can publish a revoked state whenever they like, and everything above says you cannot defend it. A close attempted at 961,632 is therefore close to worthless — and the last‑minute rush is exactly when confirmation is least reliable, because everyone else is closing too and on‑chain fees spike accordingly.

Outcomes, best to worst:

Outcome 3 is worth understanding, because for some channels it is now the best result still available. A force close on your latest state carries no revocation risk — your counterparty was never given the revocation secret for it — so once that commitment confirms pre‑split, the delayed output is yours on every chain. You sweep it on Chain A on schedule; on a stalled Chain B it simply waits. Frozen is not the same as stolen.

Working out your own deadline, per channel:

• Cooperative close — needs your counterparty online and enough margin to confirm through a fee spike. Budget days, not blocks.
• Force close — needs the commitment to confirm, then your channel's CSV delay to elapse, then the sweep to confirm. That delay is negotiated per channel and is commonly 144 to 2,016 blocks — one day to two weeks. Look it up rather than guessing: lncli listchannels reports csv_delay, and Core Lightning's listpeerchannels reports the negotiated to_self_delay values.
• Unresponsive counterparties — you need slack to discover them and escalate to a force close. Cooperative close attempts do not fail instantly.

Given that this is being published within a few days of 961,632: for any channel whose CSV delay exceeds the time remaining, outcome 2 is already out of reach. Force close anyway. Outcome 3 is still far better than outcome 5, and it stays available right up until the last block that will confirm your commitment.

9. Decision tree — before mandatory signaling

This is the window where cheap actions are still available. After block 961,632 they are not.

Read the tree's timing literally. Every "close" branch ends at confirmed, not at broadcast. The gap between those two is where this goes wrong — see How much lead time do you need.

On-chain checklist — everyone, Lightning or not

• Work out your real deadline first, and work backwards from it. It is not 961,632 — it is however long before 961,632 your closes need in order to confirm. For most people that means acting today.
• Self-custody through the window. Coins sitting on an exchange at the split are the exchange's coins on every chain. As of publication, Start9 is not aware of any exchange having published a BIP‑110 policy. That is not reassurance: it means that if a split does happen, whether you are credited on one chain, both, or neither gets decided by each exchange after the fact, under no announced rules — and exchange terms generally allow deposits and withdrawals to be paused at any time. Not your keys, not your forkcoins.
• Verify your seed backups — actually test a restore. The same keys control your coins on every chain, and you may need them on software you have not installed yet.
• Snapshot what you own. Record your wallet descriptors / xpubs and your UTXO list, plus your node's tip height and hash, shortly before 961,632. This is your record of what you held on every chain at the moment they diverged.
• Stop accepting payments across the window if you can. If you cannot, raise confirmation requirements sharply — 1-conf is unsafe even in the no lasting split case, because orphaned non-signaling blocks cause repeated shallow reorgs.
• Decide your chain preference now, while nothing is on fire. Section 11 is much harder to work through under pressure.
• Do not move funds during the window unless you must. Anything you broadcast should be assumed to spend on every chain.

10. Decision tree — did it actually split?

Do not answer the first question from your own enforcing node's chain. During mandatory signaling an enforcing node rejects non‑signaling blocks, so the chain it follows shows 100% signaling by construction — that reading reflects the software rule, not miner behavior. The evidence lives in what your chain excludes: getchaintips branches with status invalid, or the view from a non‑enforcing node or an external block explorer.

How to tell which situation you are in

• Check the deployment state: bitcoin-cli getdeploymentinfo and look at reduced_data. On StartOS, the Runtime Information action on the Bitcoin service shows softfork state and height.
• Check for rejected branches: bitcoin-cli getchaintips. An enforcing node that is rejecting blocks will show branches with status invalid.
• Compare your tip against a reference for the chain you believe you are on — height and hash.

A stalled node looks exactly like a healthy node

This is the most dangerous detection failure in the whole event. If your node ends up on a chain with no hashrate, it does not error, warn, or disconnect. It stays "synced," keeps its peers, and reports itself healthy. It just stops receiving blocks.

Do not check whether your node is healthy. Check whether your block height is advancing, and how old your tip's timestamp is. A tip several hours stale is the signal.

11. Decision tree — after a confirmed split

Notes on each path

Why this tree can treat Chain A as the majority chain: a persistent split implies it. Had the RDTS branch taken the work lead, non‑enforcing nodes would have reorged onto it (§5) and there would be no separate Chain A left to choose. A standing two‑chain state therefore means Chain A holds the work lead — so at this node, and only at this node, "Chain A" and "the majority chain" coincide. Everywhere upstream of here, keep the two ideas separate.

Chain A — non-enforcing. Your node follows the most-work chain, Lightning works normally, fees are normal. The cost of this path is that your Chain B balance is barely defendable: if you still have channels open, a watchtower on Chain B probably will not save them (§8). Close what you have on Chain A and rebroadcast the close transaction onto Chain B — since a cooperative close spends the funding output, once it confirms there the channel is settled at the same balances. This is the one case where replay works in your favor. On a stalled Chain B it will sit in the mempool; broadcast it there with a high fee anyway, and rebroadcast every couple of weeks as mempools expire (§7). This is best-effort, not a guarantee — a revoked state paying a higher fee can still displace a queued transaction — but it costs nothing and wins if it confirms first. It is also one more reason closing before the split is the clean path.

Chain B — RDTS. You may not be able to move coins for a long time. Do not run Lightning here. Accepting on‑chain payment here is a different matter — for many RDTS operators it is the point: requiring payment on the RDTS chain is how a node expresses economic support for the rules it enforces. Just be precise about what your node is telling you. It validates receipt on this chain only; a confirmation here carries no information about the other chain, and a payer can arrange to pay you on one chain and not the other. Have no expectation of the Chain A side of a payment unless you verify it on Chain A too — check both, or price the payment as Chain B coins alone. And on a slow chain, budget for confirmations to take as long as blocks do. Your Chain A balance is still worth protecting, and this is the one direction where the watchtower approach genuinely works — a tower pointed at Chain A can get a justice transaction confirmed at normal fees.

Chain C — hard fork. Everything about this is unconfirmed until the client ships. The two things that will not change: a new proof-of-work algorithm means the entire existing mining industry cannot secure this chain, so early reorg costs are low; and a downward difficulty adjustment restarts block production, not security.

Default — preserve optionality. Genuinely a good answer. Your coins exist on every chain automatically; you do not need to do anything to "claim" them, and nothing expires. And while you are neither sending nor receiving, it does not matter which client you run — a node only binds you to a chain when you rely on it to validate a payment, so there is nothing to switch in order to stay undecided. Keep whatever you have. The one item that cannot wait, if it somehow still applies, is a Lightning channel left open — that is the standing liability of §8, and it does not get safer with time. Beyond that, sitting still keeps every option open. The only irreversible mistakes are Lightning losses and unintended replayed spends, and both are avoided by having closed and not transacting.

12. Doing it on StartOS

Switching flavors is supported — and handled correctly

Bitcoin Core, Bitcoin Knots (pre-RDTS), and Bitcoin Knots (RDTS) share the bitcoind package id and data volume, so switching keeps your synced chain — no re-sync.

This matters more than it sounds. bitcoind permanently records its verdict on every block it has seen, and those records do not note which rules produced them. A freshly switched binary trusts them as-is and never re-checks buried blocks. Left alone, that would silently pin your node to the previous flavor's chain. The StartOS packages correct this automatically on the first start after a switch:

• Leaving RDTS → blocks rejected under RDTS are reconsidered so the non-enforcing flavor can follow the majority chain. You get a "Chain Verdicts Reset" notification.
• Arriving at RDTS → the chain is replayed from height 961,632 under full RDTS validation, landing you on the best RDTS-valid chain. Takes minutes to many hours; notifications mark start and finish.

Caveats that bite during a real split:

• Pruned nodes. Re-validating or reorganizing needs block data you may have pruned. If the range is gone, the package will direct you to Reindex Blockchain — which on a pruned node means re-downloading the entire chain. A pruned node also cannot reorg deeper than its retained window.

• assumeutxo. A chainstate from a snapshot that has not finished background validation cannot be replayed yet. No action needed — it runs automatically once validation completes.

• Peers matter, but they do not pick your chain. Correcting verdicts lets your node accept the right chain; actually reaching it needs peers willing to serve that chain's blocks — and on the minority side you may not get any by default. Peer discovery hands you whoever is out there, which during a split is overwhelmingly the majority side, and those peers announce the majority tip. A minority-chain block never becomes their best tip, so they do not pass it on either. Your node can therefore sit with a full complement of peers and never learn that its own chain produced a block — fully connected, and deaf. That is when you add someone you know is on your side, via Peer Settings → Connect Peer → Add Node.

  Use Add Node, which supplements your normal peers — not Connect, which makes the list exclusive. Neither changes which chain you follow: your node validates every block itself, so peers on the other side cannot pull you onto theirs. They only cost you connection slots.

• ⚠️ Do not switch flavors with Lightning channels open. Correcting verdicts during a split can reorg your node onto a different chain, and that reorg can be deep. LND and Core Lightning are not safe against arbitrarily deep reorgs — a reorg past a channel's funding depth can force-close channels. Close first, switch second. If you have already switched, verify your Lightning state.

If the hard fork ships, it becomes another Bitcoin flavor

Nothing about the hard-fork client exists yet, and Start9 will not ship a binary it has not reviewed. But if it is released and there is demand to run it, the intent is to package it the way the existing three flavors are packaged: as another implementation of Bitcoin under the shared bitcoind package id, subject to the same review as any other package.

The practical consequence is that your dependent services would not need reconfiguring. LND, Core Lightning, BTCPay Server, Fulcrum, electrs and Mempool depend on Bitcoin generically rather than on any particular implementation, so they follow whichever flavor is installed. Running the fork would be a flavor switch — with all the caveats above, including the pruning and reorg ones — not a rebuild of your stack.

This changes nothing about the Lightning advice. Packaging cannot reach a protocol problem. A channel left open through the fork is a 2-of-2 whose pre-signed exit may not validate on the new chain (§8), and no amount of packaging can re-sign it for you. Close before the split regardless of which client you expect to run afterwards.

Before you close: turn off whatever opens channels for you

Closing is not durable while something on your node is still funding channels behind you. Disable automatic channel management before you start closing, not after. Otherwise you work down your channel list, and an agent quietly refills the capacity you just released — leaving you with fresh 2‑of‑2s funded right through the split window, which is the exact exposure you were closing out (§8). Worse, these are the channels you are least likely to notice, because you were not the one who opened them.

• LND — autopilot. The Autopilot section of the LND config (autopilot.active in lnd.conf); set it off and save. Autopilot opens channels on its own schedule against a capacity target, so a node left with it on will treat every close you make as capacity to replace.
• Core Lightning — CLBOSS. CLBOSS is the CLN equivalent of autopilot: it opens, closes and manages channels on its own initiative. Disable it in the CLN config before you start closing. Stock CLN with no such plugin opens nothing by itself.
• Anything else that can fund a channel without you. LSP integrations, mobile wallets with auto‑open, rebalancing scripts, node-management dashboards. If it can open a channel without you clicking, turn it off for the window.

Turn them back on once the outcome is clear. Until then, every channel opened is one you will have to close again under worse conditions — higher fees, less time, and possibly on a chain that is barely producing blocks.

Actions you will want

Note: Closing your Lightning channels is still the recommended flow, but if you choose not to, a cross-chain watchtower is better than nothing.

After any reorg, check every service that depends on your node: LND, Core Lightning, BTCPay Server, Fulcrum / electrs, and Mempool.

13. What not to do

• Do not leave Lightning channels open through the split. Nearly everything else here is recoverable; this and a replayed spend are not.
• Do not leave closing until the last blocks. A close that has not confirmed by 961,632 is inherited by neither chain as a settled close, and on a chain that stalls it may never confirm at all — leaving you roughly where you started. Broadcasting is not closing.
• Do not switch bitcoind flavors while channels are open. A deep reorg can force-close them.
• Do not trust low confirmations. Even in the best case — a divergence that heals — orphaned non-signaling blocks mean repeated shallow reorgs.
• Do not assume a running node is a working node. Check that your height is advancing.
• Do not leave coins on an exchange through the window.
• Do not run an unvetted hard-fork binary on a machine holding your keys.
• Do not assume a transaction stays on the chain you broadcast it to. Between Chains A and B there is no replay protection at all.
• Do not try to split coins on a chain that is not producing blocks. Nothing confirms there.
• Do not assume the hard fork has replay protection. Verify it.
• Do not assume replay protection is good news for an open channel. If it works by changing the signature hash, it invalidates the pre-signed commitment that is your only unilateral exit — your balance there becomes unrecoverable without your counterparty. Both designs are bad; only closing avoids both (§8).

Appendix: verifying the parameters yourself

# Deployment status, including reduced_data — is it STARTED, MUST_SIGNAL,
# LOCKED_IN, or ACTIVE? MUST_SIGNAL is the window this guide is about.
bitcoin-cli getdeploymentinfo

# Are you rejecting blocks? Look for branches with status "invalid".
bitcoin-cli getchaintips

# Is your height actually advancing, and how stale is your tip?
bitcoin-cli getblockchaininfo

# Whether the running binary enforces RDTS at all: the reduced_data
# deployment is present only on builds that define it. Enforcement is a
# property of the binary, not of configuration — the `consensusrules`
# option records consent and silences a warning; it does not gate anything.
bitcoin-cli getdeploymentinfo | grep -A5 reduced_data

Further reading: bip110.org · bitcoinknots.org/learn/2026-rdts · Start9 Bitcoin guides