Precision notes on fingerprints/payjoin.md (Ex1 low-R, Ex3 nSequence)

[bc1cindy]

cross-ref against #1597

the thesis holds and none of these notes change the examples' conclusions, these are attribution/precision notes:

• Ex3 - Cake's 0x01: not a deliberate BIP-68 timelock, it's replaceByFeeSequence (=1, an RBF signal) applied only to inputs[0] (the group-C bug). same byte, fixable bug, not an intentional timelock.

• Ex3 - "3fbe1713 = BBM's standard behavior" (all MAX): checked on-chain 3fbe1713 is version 1 and spends a Taproot (P2TR) input, while BBM is bdk-based: P2WPKH-only on both keychains (doesn't hold taproot) and signs at 0xfffffffd, never MAX (replaceByFee defaults true), so it can't be BBM-built, it's a deposit into BBM (1 taproot input → taproot change 151,351 + the 19,358 P2WPKH output BBM later contributes to the payjoin). the all-MAX is the depositing wallet's fingerprint, not BBM's. this doesn't change the partition. in_1 is still BBM's, established by the Cake-side [1,MAX] on in_0 + elimination; the 3fbe1713 all-MAX just isn't the signal that proves it.

• Ex3 - the diagram shows 3fbe17 with 2 inputs / out_0 = 430,856, but on-chain it's 1 input / out_0 = 151,351 P2TR.

• Ex1 - low-R: I believe "one of each = near-certain two implementations" is a bit strong, because non-grinding is random, so a single wallet gives one-of-each ~50% of the time. the robust signal is elimination (a high-R input rules out grinders), Ishaana's own framing (probabilistic).

none of these change the results.

value conservation + round-number payments over-determine the partition.

the two Ex3 ones tie to the nSequence groups in #1597.

suggested edits:

• Ex1: a wallet either grinds (always low-R) or doesn't (random ~50/50) → "one of each" isn't proof of two signers; reframe as elimination: "a high-R input rules out grinding wallets"
• Ex3: reframe Cake's 0x01 as the replaceByFeeSequence bug (not BIP-68); fix the 3fbe17 attribution (deposit, not BBM) + diagram (1 input / out_0 151,351)

c/c @arminsabouri