Payjoin receiver can contribute unconfirmed (0-conf) inputs

[bc1cindy]

the payjoin candidate filter (_filterAvailableUtxos, payjoin_repository_impl.dart) removes only locked and non-Bitcoin UTXOs, never confirmation depth, so the receiver can contribute a 0-conf input.

this is a temporal fingerprint: an unconfirmed-ancestor spend is observable on-chain and partitions the payjoin's anonymity set by elimination (receivers that only contribute confirmed inputs are ruled out). A 0-conf parent can also be RBF'd out, invalidating the payjoin.

fix: exclude 0-conf from the payjoin candidates (confirmations > 0). the field already exists on WalletUtxoModel. Scoped to the payjoin receiver path; normal sends are unaffected.

ref: payjoin/rust-payjoin#1597 (comment)

[BullishNode]

Can you elaborate more about how this partitions by elimination? Both sender and recipient can contribute 0-conf coins so I don't see wherr the problem comes from

[bc1cindy]

Can you elaborate more about how this partitions by elimination? Both sender and recipient can contribute 0-conf coins so I don't see wherr the problem comes from

the leak is between different wallets, sender and receiver run different software, so any axis where they diverge partitions their inputs.

this issue makes the receiver converge on the safe value (confirmed-only)

makes sense?

[BullishNode]

Ability to spend a 0-conf transaction is not wallet software fingerprint. All major wallet implementations allow it afaik.

[bc1cindy]

Ability to spend a 0-conf transaction is not wallet software fingerprint. All major wallet implementations allow it afaik.

it is a fingerprint according to https://ishaana.com/blog/wallet_fingerprinting/

"Temporal fingerprints typically relate to some sort of fee-bumping and/or unconfirmed inputs."

a weak one though. there's also the robustness point, since a contributed 0-conf input makes the payjoin depend on an unconfirmed parent that can be RBF'd or evicted, invalidating the tx

[DanGould]

As a matter of convenience I know I definitely spend unconfirmed sometimes. This seems like the type of thing you could warn (if it's even a certain issue fingerprinting vs other impls) on but seems a bit overbearing to prevent outright compared to some of the others

[bc1cindy]

if the warning is only informational, the behavior is unchanged, which is itself a fingerprint and converges nothing.
if gating, user-dependent (a probabilistic fingerprint)

to fix we could default-on-with-opt-out or accept the leak(with warn?)

wdyt?

[bc1cindy]

worth looking at: https://fungi-protocol.github.io/lumen-fingerprints/