Anti-Sniping

What Is Anti-Sniping?

Anti-sniping is a transaction construction technique used by Bitcoin wallets to discourage a theoretical mining attack called fee sniping. In a fee-sniping attack, a miner with sufficient hashpower chooses to re-mine a recently confirmed block rather than build on top of it, aiming to capture high-fee transactions from that block and include them in the miner's own replacement block instead.

The defense is straightforward: when a wallet constructs a transaction, it sets the nLockTime field to the current block height. This makes the transaction invalid for inclusion in any block at a lower height. If every wallet does this, a miner attempting to re-mine an earlier block cannot include the new high-fee transactions in the replacement block, because those transactions are locked to the current height or later.

Anti-sniping is not a consensus rule or a protocol change. It is a voluntary wallet behavior that strengthens the network when adopted widely. Bitcoin Core introduced it in 2015, and other wallets like Electrum have since adopted it as well.

How It Works

To understand anti-sniping, it helps to first understand the attack it prevents.

The Fee-Sniping Attack

Imagine the blockchain is at height 800,000. A miner just found block 800,000, which contains transactions paying a total of 0.5 BTC in fees. The mempool for the next block contains transactions paying only 0.01 BTC in fees. A rational miner with enough hashpower faces a choice:

1. Build on top of block 800,000 honestly and earn 0.01 BTC in fees from the next block
2. Attempt to re-mine block 800,000 to steal the 0.5 BTC in fees, plus include any new high-fee transactions from the mempool

If the fee gap between consecutive blocks is large enough, the second option becomes economically rational. This creates a perverse incentive where miners compete to rewrite recent history rather than extend the chain, undermining the longest chain rule that Bitcoin relies on for consensus.

The Anti-Sniping Defense

Anti-sniping neutralizes this attack by constraining when transactions can be mined. When a wallet sets nLockTime to the current block height (800,000 in the example above), the transaction is only valid for inclusion in block 800,001 or later. A miner attempting to re-mine block 800,000 cannot include this transaction in the replacement block because the locktime forbids it.

If all wallets set nLockTime this way, the pool of "snipeable" transactions shrinks dramatically. The attacking miner can only include transactions that were already in the original block (which the honest chain also includes) and cannot capture newly broadcast high-fee transactions.

Bitcoin Core Implementation

Bitcoin Core implements anti-sniping in a function called DiscourageFeeSniping, introduced in PR #2340. The logic works as follows:

1. Set nLockTime to the current chain tip height
2. With approximately 10% probability, subtract a random value between 0 and 99 from the height (clamped at zero) for privacy
3. If the node is performing initial block download or the chain tip is more than 8 hours old, set nLockTime to 0 instead (since the wallet does not have reliable height information)
4. Skip the policy if nLockTime or nSequence is already set by the user

The random offset in step 2 serves two purposes. First, it provides privacy: if every transaction had nLockTime set to the exact same height, an observer could infer which block a wallet was synced to when constructing the transaction. Second, it accommodates transactions that are signed but not immediately broadcast, ensuring they remain valid after a few blocks pass.

// Simplified pseudocode of Bitcoin Core's anti-sniping logic
fn discourage_fee_sniping(tip_height: u32) -> u32 {
    if !is_current_for_anti_fee_sniping() {
        return 0; // stale tip, skip anti-sniping
    }

    // 90% of the time: use current height
    // 10% of the time: subtract random offset for privacy
    if random(0..10) == 0 {
        return max(0, tip_height - random(0..100));
    }

    tip_height
}

BIP 326 and Taproot

For Taproot transactions, BIP 326 proposes an alternative approach. Since Taproot uses Schnorr signatures and can leverage nSequence for relative timelocks, BIP 326 suggests a 50/50 split: half the time use nLockTime-based anti-sniping (as described above), and half the time use nSequence-based anti-sniping instead. This variation improves privacy by making anti-sniping transactions less distinguishable from transactions that use timelocks for other purposes, such as Lightning channel closes.

Why It Matters

Anti-sniping addresses a long-term structural concern in Bitcoin's incentive design. Today, the block subsidy (currently 3.125 BTC per block after the 2024 halving) dwarfs transaction fees in most blocks. A miner would gain little by re-mining a recent block for its fees when the subsidy is the same regardless of which block they mine.

But the subsidy halves approximately every four years and will eventually approach zero. As fees become a larger share of miner revenue, the variance between blocks grows significant. A block with 1 BTC in fees next to a block with 0.02 BTC in fees creates a strong incentive to re-mine the richer block. This is the core of the security budget debate: whether Bitcoin's fee market alone can sustain enough miner revenue to keep the network secure against reorg attacks.

Anti-sniping is one piece of this puzzle. It does not solve the security budget problem on its own, but it directly reduces the profitability of fee-sniping attacks. When widely adopted, it makes honest mining relatively more profitable compared to reorg-based strategies. Research has shown that wider use of transaction lock fields could reduce the payoff from fee-sniping attempts, making honest chain extension the dominant strategy even when fee variance is high.

For a deeper analysis of how Bitcoin's security model evolves as subsidies decline, see the research article on Bitcoin's fee-only security budget.

Use Cases

Wallet Transaction Construction

The primary use case is straightforward: every time a wallet creates a transaction, it should set nLockTime to the current block height. This is the default behavior in Bitcoin Core, Electrum, and several other wallet implementations. Wallet developers building on Bitcoin SDKs should ensure their transaction construction logic includes anti-sniping by default.

Layer 2 Protocol Transactions

Layer 2 protocols that create on-chain transactions can also benefit from anti-sniping. When a Lightning channel is cooperatively closed, or when a splice transaction is broadcast, setting nLockTime to the current height ensures these transactions contribute to anti-sniping as well.

Exchange and Institutional Wallets

Exchanges and custodians that process large volumes of batched transactions have an outsized impact on anti-sniping adoption. A single large exchange implementing anti-sniping can meaningfully increase the share of transactions that carry a locktime, making fee sniping less viable across the network.

Risks and Considerations

Privacy Fingerprinting

Setting nLockTime to the exact current height can reveal information about when and where a transaction was constructed. If a node is stuck on a stale block, its transactions may carry a distinctive locktime that differs from the rest of the network, allowing observers to cluster transactions by wallet. Bitcoin Core's random offset (subtracting 0-99 blocks with 10% probability) partially mitigates this, but the pattern is still identifiable for chain analysis tools.

Incomplete Adoption

Anti-sniping only works as a collective defense. If only a fraction of transactions use it, the remaining transactions without locktime constraints remain available for sniping. Estimates suggest that roughly 20% of Bitcoin transactions used anti-sniping locktime as of 2021. While this is meaningful, broader adoption across all major wallets would significantly strengthen the defense.

Not a Complete Solution

Anti-sniping reduces the profitability of fee sniping but does not eliminate it entirely. Transactions that were already in the original block can still be included in a replacement block. And transactions constructed with nLockTime set to 0 (either intentionally or due to stale chain tips) remain snipeable. Anti-sniping is best understood as one layer of defense within a broader set of mechanisms that protect Bitcoin's security budget.

Interaction with Replace-by-Fee

When a transaction is fee-bumped via replace-by-fee (RBF), the replacement transaction should also carry an appropriate nLockTime. A recent Bitcoin Core discussion identified that fee-bumped transactions created after a long offline period could inadvertently set nLockTime to 0, dropping below the original transaction's locktime and creating a wallet fingerprint. Ongoing development work continues to address these edge cases.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.