Tracking: chain-observable transaction-level fingerprinting

[bc1cindy]

payjoin's privacy collapses when sender's and receiver's wallets produce divergent transaction-level fingerprints. a chain analyst then partitions the merged tx back into per-owner inputs. primarily through the backward channel, since the lib already coerces intra-tx uniformity for nSequence (see receive/common/mod.rs:280-317 and send/mod.rs:391,1295).

complements #1586 (network-level): this covers nSequence divergence in prior transactions feeding a payjoin, what any chain observer sees after broadcast.

verified across the same six integrations. each wallet's own nSequence policy (used in its non-payjoin transactions, which become payjoin inputs) splits into two groups (the second a bug):

group A - uniformly 0xFFFFFFFD (ENABLE_RBF_NO_LOCKTIME):

• payjoin-cli via Bitcoin Core's walletcreatefundedpsbt (RBF default since v0.16)
• ldk-node bdk_wallet 2.3.0
• Liana spend.rs:773
• Boltz boltz-core/src/bitcoin/tx.rs:179
• Bull Bitcoin Mobile bdk_wallet_datasource.dart:202-204 (bdk_dart default 0xFFFFFFFD; set to 0xFFFFFFFE only when replaceByFee == false, which defaults true send_state.dart:82)

group C - mixed [0x01, 0xFFFFFFFF, …] (bug):

• Cake Wallet transaction_builder.dart:402-406 applies replaceByFeeSequence only to inputs[0]; remaining inputs stay at defaultTxSequence. Combined with electrum_wallet.dart:1516, every multi-input cake tx with confirmed UTXOs has the deterministic pattern [0x01, MAX, …, MAX], propagating through the spending graph.

empirical confirmation in How Fingerprints Damage PayJoin Privacy @arminsabouri: a real Cake → BBM payjoin is intra-uniform (the lib coerces receiver to match sender's nSequence), but Cake's prior tx carries the [1, MAX] pattern from the group C bug, propagating Cake-ownership via the backward channel and recovering the partition.

the lib's intra-tx coerce (good!) doesn't reach into transactions that predate the payjoin. prior txs were built with each wallet's standard tx-construction code - the leak lives there.

should I open an issue on cake to fix group C (apply replaceByFeeSequence to all inputs, not just inputs[0])?

zooming out, same family as #1586: would an "integration conformance policy" make sense? lib defines required tx-construction behaviors (uniform nSequence, canonical sighash, etc.), enforced via sender-side validation or documented as protocol requirement, closing the divergence category at the source instead of patching wallet-by-wallet.

the target end-state is only one group. with group B dissolved, 5 of 6 already converge on 0xFFFFFFFD; only Cake's group-C bug diverges. fixing group C therefore closes the nSequence divergence entirely - there's no residual A↔B split (a payjoin-cli ↔ Boltz payjoin is already uniform). canonical convergence on 0xFFFFFFFD (Bitcoin Core default since v0.16, now used by 5 of 6) plus sender-side conformance validation is the remaining policy question.

EDIT: group B - uniformly 0xFFFFFFFF (Sequence::MAX) corrected, dissolves into group A. the old Boltz/BBM MAX was their payjoin-contributed input, which the lib overwrites with the sender's sequence at receive/common/mod.rs:285-317 it never reaches the chain. their own txs use 0xFFFFFFFD

[arminsabouri]

group C - mixed [0x01, 0xFFFFFFFF, …] (bug):

Good find. I would just upstream a fix to this file: https://github.com/cake-tech/bitcoin_base/blob/41091028100cf0e6756ed9ed73d7092fe7663d34/lib/src/bitcoin/script/op_code/constant.dart#L153

should I open an issue on cake to fix group C (apply replaceByFeeSequence to all inputs, not just inputs[0])?

and yes.

[bc1cindy]

nLockTime across the integrations: #1676

Randomized backdating (≠ exact tip):

by default, Bitcoin Core's anti-fee-sniping sets nLockTime to the current block height but ~10% of the time picks a height up to 100 blocks back, to improve privacy for transactions broadcast some time after signing (e.g. high-latency mix networks, CoinJoin) spend.cpp:1029-1031.

• Liana - reimplements Core's anti-fee-sniping: create_spend computes locktime = anti_fee_sniping_locktime() commands/mod.rs:302-313 and passes it into the tx commands/mod.rs:746. The function spend.rs:485-517 returns the current height, but ~10% of the time (clock precision permitting) subtracts 1-100 blocks; it returns 0 if the tip is >8h old spend.rs:45 or its timestamp is unknown. So ~10% of Liana prior txs sit below the tip.

Exact-tip (locktime = current block height, no randomization):

• payjoin-cli opts out of this: it sets an explicit locktime = get_block_count() wallet.rs:54-59, passed to walletcreatefundedpsbt. Core writes it into rawTx.nLockTime via ConstructTransaction rawtransaction_util.cpp:151-155, then FundTransaction copies it into coin_control.m_locktime spend.cpp:1505-1512, and a set m_locktime disables anti-fee-sniping spend.cpp:1324-1327 so ~10% randomization never runs. The code comment calls this "an opinionated default for external wallet integrations to follow."
• ldk-node - wraps bdk_wallet 2.3.0. Its on-chain send (send_to_address, wallet/mod.rs:710-769) builds via build_tx without calling .nlocktime() in any branch, so bdk's no-locktime arm applies: fee_sniping_height = current_height, no subtraction mod.rs:1433-1452. Its channel-funding path sets an explicit locktime, but also to the exact current height event.rs:628-629, so every ldk-node tx is exact-tip.
• Bull Bitcoin - wraps bdk_wallet 2.3.0 via bdk-flutter. Its builder bdk_wallet_datasource.dart:168-244 sets only sequence (setExactSequence) and fee, never a locktime, so the same bdk no-locktime arm applies → exact current height.

these three converge on exact-tip, distinguishable from core-standard wallets, but not from each other.

Protocol-driven

• Boltz: swap timeout height. Refund requires it Refund.ts:12-37; claim optional Claim.ts:69-79.

No anti-fee-sniping

• Cake: always 0. Cake builds via BitcoinTransactionBuilder electrum_wallet.dart:1354, which has no locktime parameter and constructs BtcTransaction without a lock transaction_builder.dart:561; BtcTransaction then defaults locktime = lock ?? DEFAULT_TX_LOCKTIME transaction.dart:33 = [0,0,0,0] constant.dart:361. No anti-fee-sniping anywhere.

Backward-channel consequence:

four groups - exact-tip {payjoin-cli, ldk-node, BBM}, backdate {Liana}, protocol {Boltz}, zero {Cake}.

tip is shared by the exact-tip cluster and Liana ~90% of the time; 0 is emitted not only by Cake but by any anti-fee-sniping wallet on a stale/unknown tip or lagging chain. The distinctive signals are Boltz's swap-timeout height (a specific non-tip value), Cake's 0 across its entire history, and Liana's ~10% below-tip tail over several txs. Only the exact-tip cluster {payjoin-cli, ldk-node, BBM} fully converges -- the value payjoin-cli explicitly proposes as a default.

[bc1cindy]

following the nLockTime analysis, the same cluster {payjoin-cli, ldk-node, BBM} converges on the privacy-preserving default on a third construction axis, change position, while Liana and Cake diverge

Output ordering (change position) across the integrations

Randomized (change index shuffled, hides which output is change):

• payjoin-cli (Core) its walletcreatefundedpsbt options set no change position wallet.rs:47-52, so Core hits the !change_pos branch and inserts change at a random position spend.cpp:1264-1270.
• ldk-node and Bull Bitcoin inherit bdk_wallet 2.3.0, whose TxOrdering defaults to Shuffle tx_builder.rs:846-850, which shuffles the output vector tx_builder.rs:893. Neither sets an ordering: send_to_address wallet/mod.rs:710-769 calls no .ordering(), and BBM's builder bdk_wallet_datasource.dart:168-244 sets none.

Deterministic position (insertion order, not shuffled - change identifiable by position):

• Liana appends change last, after the recipients, with an explicit // TODO: shuffle once we have Taproot
spend.rs:744-753.
• Cake appends the change output last electrum_wallet.dart:990; the code confirms it. // Here, lastOutput already is change electrum_wallet.dart:1118-1119. It builds with outputOrdering: BitcoinOrdering.none electrum_wallet.dart:1360, and bitcoin_base applies no sort for none, appending any OP_RETURN memo after the change transaction_builder.dart:435-452. So change is the last output (before an optional memo), never shuffled.

Single-output sweep (no change) - Boltz: claim/refund txs have one output (the destination), no change to place Claim.ts:77-93.

Backward/forward-channel consequence:

change position is a per-output property and targets the analyst's central goal: change identification. Liana and Cake place change deterministically last, so their prior (backward) and future (forward) txs expose it by position; the randomizing cluster {payjoin-cli, ldk-node, BBM} hides it. But the signal is distributional: in a 2-output payment a shuffling wallet also lands change last ~50% of the time, so it firms up only over several of a wallet's txs and is decisive on a single tx only for 3+ outputs.

[bc1cindy]

Input ordering across the integrations

the order of inputs in each wallet's standard tx (BIP-69 sorted vs shuffled vs selection order):

Shuffle (randomized input order):

• payjoin-cli (Core) funds via walletcreatefundedpsbt, and Core builds the final input vector shuffled — selected_coins = result.GetShuffledInputVector() spend.cpp:1275-1276.
• ldk-node and Bull Bitcoin inherit bdk_wallet 2.3.0, whose TxOrdering defaults to Shuffle tx_builder.rs:846-850, which shuffles the input vector tx_builder.rs:893-895. Neither sets an ordering: ldk-node's send_to_address wallet/mod.rs:710-769 calls no .ordering(), and BBM's builder bdk_wallet_datasource.dart:168-244 sets none.
• Cake - now shuffles Shuffle input order on bitcoin sends cake-tech/cake_wallet#3379

BIP-69 lexicographic (sorted by txid, then vout):

• Boltz sorts inputs explicitly - // BIP69 lexicographical input ordering / [...utxos].sort(compareInputs) Claim.ts:74-75, where compareInputs orders by txid then vout Bip69.ts:16-19.
• Cake uses bitcoin_base's default inputOrdering: bip69 transaction_builder.dart:43 the call site passes only outputOrdering, not inputOrdering electrum_wallet.dart:1354-1362 so inputs are sorted by txid then vout transaction_builder.dart:381-396. moved to Shuffle

Selection order (no sort, no shuffle):

• Liana pushes inputs in coin-selection order, iterating the selected coins directly with no sort or shuffle spend.rs:767-776.

Backward/forward-channel consequence:

input order is checkable from the tx alone (are the n inputs sorted by txid/vout?), no change-ID needed. A shuffling wallet lands on that exact order only by coincidence, so a multi-input prior tx in BIP-69 order is a strong Boltz/Cake Boltz tell. The shuffle cluster {payjoin-cli, ldk-node, BBM, Cake} hides it; Liana's selection order falls in the same not-BIP-69 bucket as the shufflers. Convergent set: {payjoin-cli, ldk-node, BBM, Cake}.

[bc1cindy]

receiver input selection (UIH2 avoidance) across the integrations:

unlike the deterministic axes (nSequence, nLockTime, input type), this one isn't a per-wallet value that convergence eliminates

• UIH2 is a collaboration artifact: the observable is whether the receiver's contributed input leaves the tx with an input smaller than its smallest output ("unnecessary input"), a property of the values, so it's probabilistic and not closeable by making wallets uniform.

the lib's best-effort mitigation try_preserving_privacy (receive/common/mod.rs:207-275) picks, for a 2-output tx, a contributed input keeping min(in) > min(out); otherwise it silently falls back to the first candidate. so the per-wallet difference is just whether the receiver even attempts avoidance:

routes through it - single input, no self-added outputs:

• payjoin-cli - Core listunspent defaults, no integration filter wallet.rs:172-179 → select + one input v2/mod.rs:896-906
• ldk-node - all list_unspent_utxos, no filter manager.rs:447-464 (called at :418) → try_preserving_privacy :430 → one input :435
• Bull Bitcoin Mobile - all wallet getUtxos payjoin_repository_impl.dart:282, minus payjoin-locked via _filterAvailableUtxos(unspentUtxos, lockedUtxos) :416-417 (body only drops locked + keeps bitcoin :447-453), passed as candidates :438 → tryPreservingPrivacy pdk_payjoin_datasource.dart:265 → one input [inputPair] :276-277
• Boltz - hot-wallet list_unspent, no filter payjoin/mod.rs:285-289 → try_preserving_privacy :291-293 → one input :295-296 (draft - "consolidation" multi-input not implemented yet)
• Liana - confirmed coins built into candidates, no filter receiver.rs:173-220 → try_preserving_privacy :228 → one input :237

skips it (bug):

• Cake Wallet - the receiver creates the WantsInputs (pj5) via commitOutputs and, in the same contiguous block, picks unspent[0] and contributes it via pj5.contributeInputs - pj5's whole lifecycle (create → contribute) is here, with no tryPreservingPrivacy call payjoin_receive_worker.dart:175-183. the selector isn't missing - it's defined on that same WantsInputs in the payjoin_flutter ref cake pins receive.dart:363; cake just skips it

why universal adoption doesn't close it: the selector is best-effort by construction - it only acts on 2-output txs, otherwise returns the first candidate, and even then can only pick among the UTXOs the receiver holds (receive/common/mod.rs:207-275). so calling it lowers the leak rate but can't guarantee UIH2 avoidance. Example 3 (Cake → BBM) in How Fingerprints Damage PayJoin Privacy by @arminsabouri illustrates a real payjoin that still decomposed - the receiver's 19,358-sat input read as UIH2/peel-chain, value conservation + a round 10k payment fixed the output partition, and the prior-tx nSequence (backward channel) completed it. Cake skipping the selector is strictly worse, but none are immune.

cake should route its receiver through tryPreservingPrivacy, I'll open an issue and PR there

[bc1cindy]

input script type across the integrations: #1722

each wallet's UTXOs carry a script type fixed by the UTXO being spent. the lib's input normalization is field-level. contribute_inputs overwrites each contributed input's sequence receive/common/mod.rs:285-317 but script type isn't a rewritable field, so a sender/receiver type mismatch can't be normalized away (only matched-when-available or flagged). the type then partitions the inputs.

P2WPKH (uniform - no leak among them):

• payjoin-cli - Core getnewaddress, no type arg wallet.rs:163-166 → inherits Core's default address type (bech32/P2WPKH)
• ldk-node - BDK Bip84 descriptors builder.rs:1462-1463
• Bull Bitcoin Mobile - default ScriptType.bip84 create_default_wallets_usecase.dart:33 →Descriptor.newBip84 descriptor_derivation.dart:20-21

distinctive type (partition signal vs the cluster):

• Liana - descriptor is only ever wsh() or tr() miniscript descriptors/mod.rs:792-819 carrying an older() timelock branch (test: wsh(or_d(pk,and_v(v:pkh,older(52560)))) :862) a witness no P2WPKH wallet produces under wsh() (or a tr() recovery/script-path spend)
• Cake Wallet - holds 5 types electrum_wallet_addresses.dart:25-30; coin selection filters only coin-control (sending/frozen) and an mweb-vs-non-mweb check, never among bitcoin script types, and the default any passes every type electrum_wallet.dart:877-902, tagging each input's own type :970 → can mix types in one tx
• Boltz (draft, #1430) - receiver lists its wallet UTXOs, sorts them by amount, and contributes the smallest one that fits payjoin/mod.rs:518-542; the input type is re-derived from the UTXO's address (is_p2wpkh → new_p2wpkh, is_p2tr → new_p2tr_keyspend, else generic new) payjoin/mod.rs:544-575, never matched to the sender. The UnspentOutput struct carries only txid/vout/address/amount/asset (no redeem_script/witness_script) → whatever type the wallet holds (Core wallet: default P2WPKH, taproot supported)

so a payjoin pairing the P2WPKH cluster with Liana/Cake/Boltz carries mixed input types, so the type cleanly partitions sender vs receiver inputs. unlike the probabilistic axes, this is deterministic per wallet and visible directly on-chain.

[bc1cindy]

sighash serialization (taproot 64 vs 65-byte) across the integrations:

only exists for taproot key-path (Schnorr) spends: SIGHASH_DEFAULT (0x00) omits the sighash byte → 64-byte sig (canonical); an explicit SIGHASH_ALL (0x01) appends it → 65-byte (Example 2's "bug"). for ECDSA (P2WPKH) the byte is always present, so there's no 64-vs-65 choice. it's a signing-side decision, the lib only predicts/preserves it (new_p2tr_keyspend assumes 64-byte default receive/mod.rs:34-36).

all converge on 64-byte SIGHASH_DEFAULT (uniform, no leak):

ECDSA P2WPKH → no taproot key-path, so no 64-vs-65 choice (N/A). proof each is P2WPKH:

• payjoin-cli - Core default P2WPKH wallet.rs:163-166
• ldk-node - single Bip84/wpkh descriptor builder.rs:1462-1463
• Bull Bitcoin Mobile - default ScriptType.bip84 → newBip84 create_default_wallets_usecase.dart:33

taproot signers, each → 64-byte SIGHASH_DEFAULT:

• Cake Wallet - signs taproot with 0x00 (TAPROOT_SIGHASH_ALL = 0x00 constant.dart:353) and appends a byte only if sighash != 0x00 ec_private.dart:111-112 → 64-byte
• Boltz - SigHash.DEFAULT then bare witness = [signature] (no byte), script- and key-path boltz-core Claim.ts:145-155 → 64-byte
• Liana - TapSighashType::Default signer.rs:296 → serialized to 64-byte (rust-bitcoin appends the byte only if type != Default crypto/src/taproot.rs:72-94)

so sighash is uniform here (all 64-byte), not a partition signal

[bc1cindy]

low-R grinding (ECDSA 71 vs 72-byte) across the integrations:

ECDSA only (Schnorr/taproot sigs are fixed 64-byte, no low-R notion). a signer that grinds loops the nonce until r < 2^255 → 71-byte DER sig (low-R); without grinding ~50% are high-R (72-byte). it's probabilistic but works by elimination: a single high-R sig rules out every grinding wallet. chain-proven in Example 1 (8dba6657…, testnet): in_0 = 71-byte (low-R), in_1 = 72-byte (high-R) → two different signers.

all grind low-R → 71-byte (uniform among the six):

• payjoin-cli - delegates signing to Core's walletprocesspsbt wallet.rs:95-99 (called in finalize v2/mod.rs:926-928); Core's CKey::Sign grinds for low-R - grind defaults true key.h:149 via the loop in key.cpp:219-222 → 71-byte
• ldk-node / Bull Bitcoin Mobile - both grind via BDK's sign_ecdsa_low_r when allow_grinding is set signer.rs:586-589 (default true :861). ldk-node uses SignOptions::default() wallet/mod.rs:452; BBM sets allowGrinding: true explicitly bdk_wallet_datasource.dart:299
• Liana - sign_ecdsa_low_r on the wsh/ECDSA path signer.rs:273
• Boltz - passes lowR=true to signECDSA Claim.ts:201 → @scure/btc-signer (pinned ^2.2.0) grinds: signECDSA(…, lowR) loops until low-R utils.ts:162-176
• Cake Wallet - bitcoin_base's signInput → btcSigner.signTransaction ec_private.dart:87-91 → blockchain_utils grind loop while (lengthR == 33) re-signs with extra entropy until low-R bitcoin_signer.dart:121-129

so all six grind → 71-byte uniform → no divergence between them, but because they all grind, a high-R (72-byte) input is a clean elimination, it can't be from any of the six. so in a payjoin a high-R input partitions out a non-grinding counterparty (exactly Example 1: low-R vs high-R = grinder vs non-grinder). uniform among these, but the axis still cuts when one side is a non-grinding wallet outside the set

[bc1cindy]

transaction version (nVersion 1 vs 2) across the integrations:

in a payjoin the nVersion is the sender's: a rust-payjoin/PDK sender refuses to finalize any proposal whose version differs from its original PSBT, enforcing proposal.version == original.version send/mod.rs:257 → basic_checks/VersionsDontMatch (a receiver that altered it would just abort the payjoin). so version can never be an intra-tx asymmetry the way the other axes can.

it's an Independent fingerprint (Ishaana), observable in one tx, and these six all sit on the modern side:

all stamp nVersion = 2:

• Liana- explicit: the spend builder hardcodes version: bitcoin::transaction::Version::TWO spend.rs:651; the payjoin receiver only contributes inputs and never references version receiver.rs
• Cake Wallet - for bitcoin (the non-BCH branch electrum_wallet.dart:1516-1536) it builds via BitcoinTransactionBuilder with no version arg; that builder constructs BtcTransaction(...) without a version transaction_builder.dart:561, which defaults version ?? DEFAULT_TX_VERSION transaction.dart:34 = [0x02,…] constant.dart:369 = v2
• ldk-node- builds via BDK's build_tx() wallet/mod.rs:437 and never calls .version() (none of its 6 build sites do); BDK's version is set only by that method tx_builder.rs:559, so it stays None → None => transaction::Version::TWO bdk_wallet@2.3.0 mod.rs:1420 = v2
• Bull Bitcoin Mobile - builds via the bdk-dart TxBuilder bdk_wallet_datasource.dart:184 without .version(); the bdk-ffi binding defaults version to None and forwards to bdk_wallet only if set bdk-ffi tx_builder.rs:73,528, so the same bdk_wallet 2.3.0 default applies = v2
• payjoin-cli - its WalletCreateFundedPsbtOptions has no version field wallet.rs:47-52, so it never sets walletcreatefundedpsbt's version arg, which defaults to DEFAULT_WALLET_TX_VERSION Core spend.cpp:1738 = CTransaction::CURRENT_VERSION coincontrol.h:25 = {2} transaction.h:284 = v2
• Boltz - acts only as the input-contributing receiver (built on payjoin::receive's NewReceiver payjoin/mod.rs:67); it builds only per-input structures (TxIn + psbt Input), never a Transaction input_pair_from_list_unspent:301-324, and the file has zero version ref, so the final nVersion is the sender's, preserved

so the axis is uniform among the six, all v2, no divergence between them, but since some wallets still emit v1 (Ishaana), it cuts by elimination. a v1 payjoin, or a v1 parent in the backward channel, rules out all six. Armin's Example 3 shows exactly this: the prior tx 3fbe1713… is v1, the payjoin 8fb80573… v2. uniform here, but it partitions once a v1 wallet is on one side.