Skip to content

Implement JoinMarket n_locktime Coinjoin detection#26

Draft
bc1cindy wants to merge 4 commits intopayjoin:masterfrom
bc1cindy:JM-locktime
Draft

Implement JoinMarket n_locktime Coinjoin detection#26
bc1cindy wants to merge 4 commits intopayjoin:masterfrom
bc1cindy:JM-locktime

Conversation

@bc1cindy
Copy link
Copy Markdown
Contributor

adds JoinMarket Coinjoin detection based on n_locktime` field, covering both block height (without fidelity bond) and Unix timestamp (with fidelity bond) cases and tests.

parte of #5

Comment on lines +36 to +41
tx.locktime() >= 1 && tx.locktime() <= 499_999_999
}

/// Unix timestamp locktime, defined by Bitcoin protocol >= 500_000_000.
pub fn with_fidelity_bond(tx: &impl HasNLockTime) -> bool {
tx.locktime() >= 500_000_000
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this sufficient? Any txs with these locktimes will get missclassified as a joinmarket tx.
Can you provide the docs that led you to this conclusion

Copy link
Copy Markdown
Contributor Author

@bc1cindy bc1cindy Mar 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was based on https://learnmeabitcoin.com/technical/transaction/locktime/

I actually had the same concern about both paths and you're right, I'm going to add more specific joinmarket checks

to be more specific in without_fidelity_bond, since locktime is relative to when the transaction was created we would need to know the block height at that time, can we expose like a HasBlockHeight?

#5 (comment)

# set locktime for best anonset (Core, Electrum)

it would still be a weak filter since they do the same for anonset

with_fildelity_bond at first I thought that being set as u32 would be enough, but we can really have better filters and HasBlockHeight would be great on that too

@arminsabouri arminsabouri marked this pull request as draft March 30, 2026 13:39
@arminsabouri
Copy link
Copy Markdown
Collaborator

Converting this to a draft for now

@bc1cindy bc1cindy marked this pull request as ready for review April 3, 2026 22:08
@bc1cindy bc1cindy requested a review from arminsabouri April 3, 2026 22:08
Copy link
Copy Markdown
Collaborator

@arminsabouri arminsabouri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is alot left here. I don't know too much about the join market protocol. The current state of things only scrutinizes the nlocktime value i believe there is more to look at (# of inputs, # of outputs, output value decomposition) + we should add tests from real join market txs

@bc1cindy
Copy link
Copy Markdown
Contributor Author

There is alot left here. I don't know too much about the join market protocol. The current state of things only scrutinizes the nlocktime value i believe there is more to look at (# of inputs, # of outputs, output value decomposition) + we should add tests from real join market txs

there is a lot left ( #5 (comment) ), but my idea was to add others in follow up PRs

but its better to add here and write tests with real txs to check the detection

I'll also add more context on the PR description to make it easier to review it

sounds good?

@bc1cindy bc1cindy marked this pull request as draft April 15, 2026 14:58
@arminsabouri
Copy link
Copy Markdown
Collaborator

Sounds good to me. Starting small is fine. Please also take a look at other codebases for inspiration. For example: https://github.com/Copexit/am-i-exposed/blob/main/src/lib/analysis/heuristics/coinjoin-detectors.ts#L73

Im not sure how important the fidelity bond tx is for classifying the actual coinjoin tx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants