Nostr Web Client

JoinMarket NG

Announcing today a full rewrite of all JoinMarket components in modern Python. Focusing on performance, maintainability, and extensibility. While maintaining compatibility with the existing JoinMarket network.

https://github.com/m0wer/joinmarket-ng

Why JoinMarket? Has no central coordinator: most censorship resistant and peer to peer.

Why a rewrite? The reference implementation has served the community well for years, and we're deeply grateful for all that the contributors have done. However, the project is no longer actively developed (181 open issues and 41 open pull requests) and had architectural limitations such as relying on Bitcoin Core's BerkeleyDB wallets (deprecated since v26.0.).

New features:

- Support for light clients using Neutrino

- Rate limiting to prevent logs flooding

- Extensive protocol and implementation documentation

- Realistic E2E tests including reference implementation makers and takers

Future plans:

- Nostr relay integration

- Lightning Network integration (CoinJoinXT) to hide roles and eliminate fee traces

- A lot more ideas

Help wanted:

- Funding: Applied to HRF Bitcoin Dev Fund and soon to OpenSats. Other grant ideas or direct donations welcome.

- Security: Need sponsorship or a volunteer for external security audit.

- Contributors: Peer review, testing, documentation.

Entrypoint for migrating makers: https://github.com/m0wer/joinmarket-ng/tree/master/maker#migrating-from-joinmarket-reference-implementation

The reference JoinMarket served us well for a decade. Let's make sure the protocol thrives for the next one.

Reply to this note

Please Login to reply.

Discussion

IrrelevantBoB 3h ago

LFG!

waxwing 3h ago

Nice to see! Apart from the code itself, did you have ideas about changing things architecturally? Thinking especially about the communication layer.

Well anyway I will read your repo a bit :)

waxwing 2h ago 💬 1

Ah some nice stuff in the README, like it!

Thoughts on Lightning network integration that you mentioned alongside CJXT, there? A number of different things are possible, I'm curious what you're most interested in.

m0wer 2h ago

I wanted to talk with you about that! Nice that you asked.

About the first question, no changes yet. The "features" field in the handshake has been extremely helpful to not have to create a new major version. And we'll try to jeep things that way as long as possible.

About CJXT. The end goal is what you described in your video. But a nice starter would be to hide roles by moving fees to LN somehow.

BTW feel free to open issues for ideas and discussions.

waxwing 2h ago

about the LN fees: it's a bit more than a nice starter I think! it would make the system an order of magnitude more useful imo (no fee fingerprint on chain) but I'm curious what you have in mind for how it could work. The way I saw it you essentially would need something equivalent to a submarine swap but with privacy, which means adaptors, which means PTLC and taproot and Schnorr (I'm thinking: payment secret is revealed by publishing signature for coinjoin). Even if that line of thinking is coherent, it's not only complex to implement, but relies on things that don't exist. Perhaps it could be done with ECDSA adaptors, which do exist, but .. well I hope it's already obvious why I always saw it as kind of "out there". Do you have something simpler (or just, better) in mind?

Peter Todd 2h ago 💬 1

Do you have a plan to fix the fee amounts flaw?

https://petertodd.org/2025/coinjoin-comparison#joinmarket

m0wer 2h ago

Yes! Just re-read your article today. The idea is to move the fees to LN, see the other thread with @waxwing .

You might find this interesting BTW: https://github.com/m0wer/joinmarket_analyzer

Peter Todd 1h ago

Thanks! Interesting.

Hodlcopter 16m ago

🚀