SegWit replay is a 2017 problem in a 2026 chain. The box is closed. The signature is portable. The two are not the same thing.

SegWit replay: when a pre fork output reopens the box

Updated 6 October 2026

That is a replay. It is not a fork. The fork gives you two chains. The replay takes one signature and uses it on the other. The box stays closed on the original chain. The witness that opens it does not care which chain you ask.

Two chains, one witness

When a chain splits, every output on the old chain is also an output on the new chain, at least until one side takes steps to stop that. Bitcoin's 2017 split solved this with a flag. The new chain, the one we now call Bitcoin Cash, changed its signature hash. The old chain, Bitcoin, kept it. A signature built for one stopped working on the other. That is the standard replay defence, and it has held for nine years.

SegWit broke the assumption behind that defence. The witness is a separate data structure. The signature is inside the witness. The script that gets executed is inside the witness. None of it is committed to in the same place as a pre SegWit signature. The flag that protected Bitcoin in 2017 sits in a field that SegWit outputs do not use the same way. So the question for 2026 is not whether a future fork can replay a SegWit transaction. It is whether a SegWit witness, lifted whole, can be made to open a box on a chain it was never sent to.

The short answer is yes, for some boxes, under conditions that are not exotic. The longer answer is what this page is for.

What SegWit moved, and where it sits now

Before SegWit, a Bitcoin signature sat next to the public key, in the same part of the transaction. The whole thing went into the block. Validators checked the whole thing. The signature was a peer of the input amount, the sequence number, the previous output's script. Changing the chain rules meant changing how the signature was built, and that meant the old signatures could not be lifted.

SegWit moved the signature, the public key, and the script into a separate structure, the witness, and put the witness in a tree that the block commits to but the old transaction format did not. The original transaction, the part that looks like a Bitcoin transaction, now contains a placeholder. The placeholder points at the witness. The witness contains the actual proof.

Two consequences follow. First, the part of the transaction that old nodes see is now a stripped down object. It looks like a transfer with no proof attached. Second, the proof itself is portable in a way it was not before. Any chain that understands the SegWit template can read the witness and run it.

This is why SegWit is, in a narrow sense, replay friendly. Not because Bitcoin is replay friendly, but because the witness is, by design, a self contained proof of authority for a specific output template.

The replay path, step by step

Imagine a SegWit P2WPKH output, the kind held by most wallets today. The output commits to a public key hash. To spend it, the witness contains a signature and a public key. The signature is built over a hash that includes, among other things, the version, the locktime, the inputs, and the outputs. Specifically, the outputs on the spending transaction.

If a fork does not change the SegWit output template, and does not change the signature hash, then a witness built on the original chain is also a valid witness on the new chain, provided the spending transaction's outputs are present on the new chain. The signature opens the box on both.

This is the part that catches people out. The box, the SegWit output, is closed on both chains. The witness opens it on both chains. The two chains disagree about which transactions are valid history, but they can agree about the shape of a single output and the proof that unlocks it.

The 2017 defence relied on the spending transaction having different outputs on the two chains, so the signature hash would differ, so the signature would only verify on the chain it was built for. For a future fork that keeps SegWit intact, that defence is gone unless the fork also changes the signature hash, which is a harder change to justify.

Where the defence has to move

Replay resistance for SegWit coins cannot sit inside the box. The box is the same box on both chains. The defence has to sit inside the witness, or around the spending transaction in a way the witness is forced to notice.

One option is a chain ID. A chain ID is a value mixed into the signature hash, so that a signature built for chain A is not valid on chain B. This is what some altcoins adopted after the 2017 split. Bitcoin does not use one. Adding one to Bitcoin would be a soft fork that touched every SegWit output. It is not a small change.

Another option is to require the witness to commit to a specific chain through some other field, for example a taproot annex, a covenant, or a separate opcode. Each of these is a protocol change, and each is its own debate.

For the user holding a closed box, the practical defence is to wait. Do not move coins immediately after a fork announcement. Wait for the dust to settle, for exchanges to credit both sides, for the replay protection story to be clear. The box does not move on its own. The signature does not move on its own. Only a broadcast moves coins. The defence is to delay the broadcast until the chains have diverged enough that a single witness cannot open the box on both.

Why a quantum fork does not have this problem

The quantum conversation that runs through the rest of this site, Shor's algorithm, the BIP 360 outputs, the post quantum signatures, looks like a replay risk from a distance. It is not. A post quantum signature is a different object from an ECDSA or Schnorr signature. The bytes are different, the verification is different, the key is different. A pre quantum witness cannot be replayed against a post quantum output because the pre quantum witness does not satisfy the post quantum script.

Where the two topics do meet is in the design of any quantum migration. If a future fork introduces post quantum outputs, the replay risk runs the other way. A witness built for the post quantum chain is not valid on the pre quantum chain, because the pre quantum chain does not know how to verify the new signature scheme. The asymmetry is in the verifier, not in the box.

This is one of the reasons BIP 360, as currently drafted, does not propose to make legacy outputs spendable by post quantum witnesses. The two script families stay separate. The boxes stay separate. The witnesses stay separate. Replay between them is not a meaningful risk because the scripts do not match.

What to do with a closed box during a fork

The standard advice holds. Do not transact during the uncertainty window. Do not paste a seed into a watch only field, ever, and especially not during a fork when phishing and fake wallet prompts peak. Watch only is for reading. It is not for signing. The box is read through a window, not opened.

If you must move coins, move them to an output type that is, as far as you can tell, native to one chain. A fresh SegWit output is native to both, at least until a chain ID is added. A fresh taproot output is also native to both for the same reason. The only way to ensure the box is closed on one chain and open on the other is to use a script that one chain rejects.

In practice, the replay window after a Bitcoin fork has been short. The 2017 split saw exchanges and wallet developers coordinate replay protection within days. A future fork, if it ever comes, will probably see the same coordination. The risk is for the user who transacts in the first hour, before the coordination lands.

The narrow case of P2PKH replay

A separate page on this site covers P2PKH replay, the pre SegWit case where a legacy output's signature can be lifted onto a chain that did not see the original transaction. That is a different mechanism, and a different defence. The SegWit case described here is about the witness, not the input script. The two are worth keeping separate, because the fix for one is not the fix for the other.

For P2PKH, the signature and the public key sit in the input. The signature is built over a hash that includes the outputs. A fork that changes the signature hash, the 2017 style, blocks P2PKH replay. A SegWit witness is structured differently. The signature hash is computed the same way, but the witness is portable because the script template is the same.

If you hold coins in both kinds of output, the replay risk is layered. A single fork can replay a P2PKH input through one mechanism and a SegWit input through another. The defences are different. The timing windows are different. The advice is the same: wait, watch, and do not sign anything during the fork window.