Anti-fee-sniping nLockTime diverges

[bc1cindy]

following up on #1597 nLockTime axis nLockTime is a per-tx fingerprint, matching the largest crowd (Core / Electrum) keeps payjoin txs in the same anonymity set.

wallet	nLockTime now	converges?
Core / Electrum	tip + ~10% backdate
Liana	tip + ~10% backdate
payjoin-cli / ldk-node / BBM	exact-tip (no backdate)	target
Cake	0
Boltz	claim 0 / refund = swap timeout

payjoin-cli sets an explicit locktime = get_block_count() (wallet.rs#L54-L59). walletcreatefundedpsbt copies that into coin_control.m_locktime (wallet/spend.cpp#L1501), and a set m_locktime turns off Core's anti-fee-sniping wallet/spend.cpp#L1313-L1316, so every payjoin-cli tx lands on the exact tip, with no backdating.

both wallets we'd want to blend into backdate ~10% of the time: Core's DiscourageFeeSniping (wallet/spend.cpp#L1029-L1030: randrange(10)==0 → nLockTime -= randrange(100)) and Electrum (wallet.py#L224-L226). Always landing on the tip separates payjoin-cli (with ldk-node and BBM) from the Core/Electrum crowd over a few transactions. The code comment cites "anti-fee-sniping best practices", exact-tip keeps the anti-snipe protection but drops the randomized backdate Core/Electrum apply for privacy, and that skip is what makes it stand out.

proposed: drop the explicit locktime and let Core's DiscourageFeeSniping run. payjoin-cli then matches Core/Electrum exactly, same anonymity set, no new coupling.

other integrations:

• Liana - already converges: anti_fee_sniping_locktime (spend.rs#L485-L516) is used in create_spend (lianad/src/commands/mod.rs#L746).
• ldk-node / BBM - exact-tip: their sends build without .nlocktime (ldk mod.rs#L743, BBM bdk_wallet_datasource.dart#L168-L204), so BDK's no-locktime arm applies, current height, no backdate (bdk_wallet mod.rs#L1439). A backdate added upstream in BDK covers both.
• Cake - always 0 (constant.dart#L148); would need anti-fee-sniping added
• Boltz - refund can't: its nLockTime must equal the swap timeout to satisfy OP_CHECKLOCKTIMEVERIFY in the swap script (SwapScript.ts#L29-L30, Refund.ts#L12-L37). The success claim isn't CLTV-bound and could converge in boltz-core: Claim.ts#L79 sets lockTime from the optional timeout, the claim path passes none so it stays 0, and its input is non-final (Claim.ts#L96) so a tip locktime would be valid.

[DanGould]

It seems like getting Cake to match is the most important outlier fix in this list

[bc1cindy]

@DanGould @arminsabouri pulled the actual numbers from that chart (date / transactions_sum / tx_timelock_height_sum): height-based locktime is ~4.5% of txs over the last 30d, down from ~18% in 2023, so ~95% use locktime=0.

so "outlier" depends on the target, and by anon-set size it's inverted: cake (0) is in the ~95% crowd, and the height wallets (payjoin-cli, ldk-node, core/electrum/liana tip+backdate) are the ~4.5% minority.

the 95% is mostly ordinals/exchange volume, and anti-fee-sniping has a real fee-sniping purpose beyond fingerprinting, so it's not purely "match the biggest crowd", but it does flip the framing: matching core here means joining the minority, not the majority.

so, before any wallet change: is the target the 0-locktime majority, or privacy-wallet behavior (height+backdate)?

ref: #1678 (review) / https://mainnet.observer/charts/transactions-height-based-locktime

[bc1cindy]

another pov is that the locktime axis has two stable crowds: 0 (~95%) and height (~4.5%)

a payjoin wallet just needs to sit in one of them, not all converge to the same target. since exact-tip-no-backdate isn't a problem (it's the modal value of the height crowd, indistinguishable per-tx), I consider this axis normalized across integrations on this research.

wdyt? makes sense?

[bc1cindy]

closing this as completed

locktime has two stable crowds, 0 (~95%) and height (~4.5%). A wallet just needs to sit in one of them, not have all of them converge on the same target.

the absence of the ~10% backdate only diverges under a statistical target (clustering analysis over many txs from the same wallet), not in an isolated tx.

that said, this is my read, if anyone disagrees or thinks the statistical angle is worth pursuing, happy to reopen and dig in.

[arminsabouri]

We may be conflating two related ideas. hiding in the larger crowd of bitcoin transactions and matching your counterparties fingerprints. Payjoins achieve their privacy goals if they look like a ordinary unilateral payments. So the statistic we want to look at is nlocktime distribution from unilateral looking payments. I would posit that most of the nlocktime=0 txs are probably from some metaprotocol (runes, ordinals,etc..) -- so they have other characteristics that we could use to filter like opreturns or other methods of embedding data. Seperately (and maybe more importantly), if most payjoin impls set nlocktime=tip, cake should follow the same behavior. Diverging fingerprints will also flag a payjoin as a non-unilateral payment.

[bc1cindy]

got it @arminsabouri, thanks for clarifying

working on it