How do I spend my BTC without accidentally spending my XBT — or spend my XBT without accidentally spending my BTC?
This is where replay attacks and replay protection become important.
The XBT/BLAKE2b fork provides a particularly interesting example because the two networks share the historical UTXO set, while using different consensus rules after the fork. A transaction that is valid under both sets of rules can potentially be replayed from one network onto the other.
There are several ways to protect against this, including XBT's SIGHASH_UNIFIED mechanism and deliberately constructing a transaction that is valid on one chain but invalid on the other.
This article explains how replay attacks work, how XBT protects against them, how BTC transactions can be separated from XBT, and how to verify that your coins have actually been separated.
What Is a Replay Attack?
A replay attack occurs when a transaction created for one blockchain is copied and broadcast onto another blockchain where the same transaction is also valid.
Imagine that Alice owns 1 BTC before the fork.
After the fork, the same underlying UTXO exists under both sets of consensus rules.
Alice creates this transaction:
Alice → Bob: 1 BTC
If the transaction is valid under both networks' rules, someone can take the exact transaction and broadcast it to both chains.
Alice intended to make one payment.
Instead, the same UTXO may be spent on both networks.
Conceptually:
Before the fork
1 BTC
↓
Fork
1 BTC and 1 XBT
↓
Alice signs a transaction
Alice → Bob
↓
Without replay protection
BTC: accepted
XBT: potentially accepted
The important point is that the coins are not duplicated by the transaction itself. The two networks simply continue to recognize the same pre-fork UTXOs until transactions make them distinct under their respective rules.
XBT Replay Protection
XBT uses a mechanism called:
SIGHASH_UNIFIED
The implementation adds a new 0x20 flag to the signature hash type. The ordinary SIGHASH_ALL, for example, becomes 0x21.
The important consequence is that the resulting signature is not valid under the pre-fork SHA-256d consensus rules. Therefore, a transaction signed using the unified hash cannot simply be copied onto the old chain and accepted.
This is important because replay protection does not depend on the wallet asking the other network to behave differently.
Instead, the signature itself is different.
The old rules simply reject it.
In simplified form
Normal signature
SIGHASH_ALL
→ valid under the old rules
→ potentially valid on both sides
XBT unified signature
SIGHASH_UNIFIED + SIGHASH_ALL
→ valid under XBT's upgraded rules
→ rejected by the pre-fork SHA-256d rules
That is the fundamental mechanism behind XBT's replay protection.
Shrike Wallet
One wallet designed specifically around these changes is Shrike, an unofficial fork of Sparrow Wallet. I have not used this wallet, so I can not vouch for it or endorse it. Use at your own risk.
Shrike signs transactions using SIGHASH_UNIFIED when replay protection is enabled. Its send screen reports whether the transaction being created actually received replay protection.
This is an important distinction:
Having Shrike installed does not mean that every transaction is automatically protected.
The wallet needs to know that the signer — particularly a hardware wallet — can actually produce the required signature type.
Shrike therefore allows replay protection to be marked on individual keystores, and the transaction itself is checked before it is broadcast.
Hardware-wallet users need to pay particular attention to this. Current Shrike documentation notes that stock firmware does not yet produce SIGHASH_UNIFIED, while unofficial firmware builds exist for certain devices. Those builds are unaudited and carry their own risks.
What About Coins You Held Before the Fork?
This is one of the most important parts of the process.
Coins that existed before activation are recognized by both sets of rules.
Therefore, simply importing a pre-fork wallet into an XBT wallet does not magically separate the coins.
Shrike recommends sending the pre-fork coins to yourself using a transaction with the unified signature. Once that transaction confirms under the upgraded rules, the resulting UTXOs have been moved under the new transaction rules.
In other words:
Old UTXO
↓
Protected XBT transaction
↓
New XBT UTXO
That self-transfer is an important step before spending the coins in situations where replay could otherwise be possible.
Does BTC Have Replay Protection?
This question needs to be phrased carefully.
The better question isn't simply:
"Does BTC have replay protection?"
The more useful question is:
"Can I create a BTC transaction that is valid on BTC but invalid on XBT?"
The answer is yes, provided the transaction uses a consensus distinction between the two networks.
This gives us a second form of replay protection.
Instead of changing the signature so that BTC rejects it, we can construct a transaction that BTC accepts but XBT rejects.
Using a Consensus Difference to Separate BTC From XBT
One example is the treatment of OP_RETURN data.
Under the XBT/BLAKE2b consensus rules, the OP_RETURN data restriction provides a way to construct a transaction that BTC can accept while XBT rejects.
For example, a BTC transaction can contain an OP_RETURN output whose payload is larger than the XBT limit.
The result is:
BTC
Transaction → valid
XBT
Same transaction → invalid
This is fundamentally different from SIGHASH_UNIFIED.
With SIGHASH_UNIFIED, the signature distinguishes the transaction.
With the OP_RETURN method, the transaction itself violates an XBT consensus rule.
Current on-chain examples and community documentation describe an OP_RETURN payload above the XBT/BIP-110 limit as a way of creating a BTC-only transaction. The commonly cited boundary is that 83 bytes are allowed while larger payloads are rejected under the XBT rules.
Conceptually
BTC transaction
↓
Valid BTC transaction
↓
XBT node examines transaction
↓
XBT consensus rule violated
↓
XBT rejects transaction
Therefore the transaction cannot simply be replayed onto XBT.
An Example: Sending BTC Without Sending XBT
The basic procedure is to first make sure the coins have been separated appropriately, then create a BTC transaction that XBT will reject.
A simplified example looks like this:
Step 1 — Identify the UTXOs
Determine which UTXOs contain the coins you are trying to separate.
Do not assume that because your wallet shows a BTC balance and an XBT balance that the underlying UTXOs are already separated.
Verify them.
Step 2 — Create a BTC transaction
Create a transaction that sends your BTC to an address you control.
For example:
Your old UTXO
↓
Your new BTC address
And add an OP_RETURN output containing data that exceeds the XBT consensus limit.
The OP_RETURN output carries no spendable value. Its purpose in this example is to make the transaction invalid under XBT's rules.
Make sure you are sending it to yourself. You need to send it to a wallet you control.
Verify Your Wallet Before and After the Transfer
This is one of the most important practical steps.
Do not simply send the transaction and assume everything worked.
Check your wallet before the transfer and again after the transfer.
For XBT, you can use:
For BTC, you can use:
These explorers allow you to inspect addresses, transactions and UTXOs on their respective networks. Please use your own nodes to check your balances'es, this helps preserve your privacy.
Before the transfer
Record:
Your address
Your balance
Your UTXOs
The transaction IDs associated with those UTXOs
Which UTXOs you intend to spend
Then check the same wallet/address on both networks.
After the transfer
Once the transaction confirms, check both networks again.
For a BTC-only separation transaction, the desired result is:
BTC
The transaction is accepted and eventually confirmed.
XBT
The same transaction is rejected and does not spend the corresponding XBT UTXO.
This provides a practical way to confirm that the transaction actually separated the coins.
But There Is an Even Better Way: Use Your Own Node
Public block explorers are convenient, but they are not the best option for privacy.
When you enter an address into a public explorer, you are revealing that address to the operator of that service.
If you repeatedly search addresses belonging to the same wallet, the operator can potentially associate:
your addresses
your balances
your transaction history
your UTXOs
your future transactions
Shrike's own documentation makes this point explicitly: a server you connect to can see the addresses you query, which can associate your wallet's activity and potentially your IP address. Running your own node avoids sending those wallet queries to someone else's server.
The privacy-first approach
Instead of:
Wallet → Public Explorer
use:
Wallet → Your Node
For BTC:
Wallet → Your Bitcoin node
For XBT:
Wallet → Your XBT/BLAKE2b-compatible node
Then verify the transaction directly against the nodes you control.
This is especially important when dealing with addresses and UTXOs that you do not want to associate with a third-party explorer.
Public explorers such as mempool.space and mempool.guide are useful as an independent secondary check, but your own node should be the primary source of truth when privacy matters.
Why Check Both Networks?
Checking only one network isn't enough.
Suppose you create a transaction and see it confirmed on BTC.
That proves that BTC accepted it.
It does not automatically prove that XBT rejected it.
Likewise, seeing a transaction rejected by XBT does not prove that BTC accepted and confirmed it.
You want to establish both sides independently.
The ideal test
| Check | Desired result |
|---|---|
| BTC node | Transaction accepted |
| BTC blockchain | Transaction confirmed |
| XBT node | Same transaction rejected |
| XBT blockchain | Original XBT UTXO remains unspent |
That is much stronger evidence that the transaction actually separated the two coins.
Two Different Ways to Protect Against Replay
There are therefore two fundamentally different approaches.
1. SIGHASH_UNIFIED
The signature itself is changed.
XBT
Transaction + SIGHASH_UNIFIED
↓
XBT accepts
BTC
Same transaction
↓
Signature does not satisfy old rules
↓
BTC rejects
This is the mechanism Shrike uses for XBT replay protection.
2. Chain-Specific Consensus Rule
The transaction itself is constructed so that one chain accepts it while the other rejects it.
For example:
BTC
OP_RETURN within BTC rules
↓
BTC accepts
XBT
OP_RETURN exceeds XBT consensus limit
↓
XBT rejects
This approach doesn't require the signature itself to be different.
Instead, the transaction is made incompatible with the other chain's consensus rules.
Post-Fork Coins Are Native to Their Own Chain
There is an important distinction between coins that existed before the fork and coins that are created after the fork.
The replay concern applies primarily to pre-fork UTXOs because those UTXOs were recognized by both chains when the networks split.
Coins created after the fork are different.
Once the two networks are operating under their separate consensus rules, newly mined coins are created by the blockchain on which they were mined. An XBT block creates XBT, while a BTC block creates BTC.
In other words:
XBT mining → new XBT
BTC mining → new BTC
There is no corresponding post-fork BTC UTXO created every time an XBT coin is mined, and there is no corresponding XBT UTXO created every time a BTC coin is mined.
This means that post-fork coins are not inherently mixed across the two chains in the same way that pre-fork coins are.
Why This Matters
Consider an XBT miner who receives a block reward after the fork.
That reward exists as an XBT UTXO on the XBT blockchain.
There is no matching BTC block reward sitting on the Bitcoin blockchain waiting to be replayed.
Likewise, when a Bitcoin miner receives a post-fork BTC block reward, that newly created BTC exists on the Bitcoin blockchain and does not simultaneously create an XBT balance.
The distinction can be illustrated simply:
Pre-fork UTXO
One historical UTXO
↓
BTC recognizes it
XBT recognizes it
↓
Replay protection may be necessary
Post-fork XBT coin
XBT block
↓
New XBT UTXO
↓
XBT recognizes it
BTC does not have the corresponding newly created UTXO
Post-fork BTC coin
BTC block
↓
New BTC UTXO
↓
BTC recognizes it
XBT does not have the corresponding newly created UTXO
The Practical Takeaway
The coins that require the most attention when separating BTC and XBT are therefore the coins that existed at the time of the fork.
Once you have received coins that were created natively on one chain after the fork, those coins are already associated with that chain's post-fork transaction history.
That does not mean that every later transaction is automatically replay-safe. You should still follow the rules of the particular wallet and chain and verify transactions when necessary.
But it is important not to confuse pre-fork shared UTXOs with post-fork native coins.
The simplest way to think about it is:
The fork created two chains from a shared starting point. It did not create a permanent mechanism whereby every new BTC coin also becomes XBT, or every new XBT coin also becomes BTC.
The shared history matters at the point of the fork. From there forward, each chain creates and tracks its own new UTXOs according to its own consensus rules.
