Encrypted Coinswap Transport with BIP324 #801
Description
Project: Encrypted Coinswap Transport with BIP324
Summary
Coinswap currently exchanges maker/taker protocol messages over plaintext length-prefixed CBOR on top of TcpStream. Tor helps with network privacy, but the application payload itself should still be protected with an authenticated encrypted transport.
This project is to design and integrate a BIP324-based transport layer for Coinswap using the rust-bitcoin/bip324 library, so that maker/taker communication is encrypted by default, authenticated at the peer-identity level, and usable by both legacy and taproot flows.
The project should also extend privacy protections to Nostr-based market discovery by routing that communication over Tor and pushing the system toward a no-clearnet architecture wherever practical.
The goal is not to replace the Coinswap protocol itself. The goal is to place a secure transport layer underneath the existing message exchange.
Problem
Today, protocol messages can leak useful metadata if observed in transit, and plaintext transport leaves too much trust in the surrounding network setup. Coinswap needs a transport layer that:
- protects message confidentiality and integrity
- authenticates the remote peer identity in v1
- works for both maker offer discovery and direct maker/taker communication
- supports both legacy and taproot protocols through one shared transport layer
- does not allow plaintext fallback in production
- reduces or removes clearnet communication from the system to improve privacy
Coinswap also needs its market-discovery path to match the same privacy goals. Nostr-based discovery should not remain a clearnet side channel if the rest of the system is being hardened.
Expected Outcome
By the end of the project, Coinswap should have a transport layer that:
- uses primitives from
rust-bitcoin/bip324as the basis for encrypted communication - is the standard default for maker/taker traffic
- authenticates the remote peer against an advertised or otherwise trusted identity
- can be integrated without rewriting the existing business protocol
- is covered by focused tests and basic migration/config support
- routes Nostr-based market discovery over Tor as part of the privacy model
- minimizes clearnet communication across the system, with the aim of removing it from normal operation
Recommended Approach
The recommended direction is to introduce a transport abstraction first, then integrate encrypted transport beneath the current CBOR message flow.
At a high level:
- Isolate transport concerns from protocol logic.
- Add an encrypted transport implementation backed by
rust-bitcoin/bip324. - Ensure the application handshake happens only after the secure channel is established.
- Reuse the same transport layer across both legacy and taproot paths.
- Extend the design to maker offer discovery, since offer traffic also leaks metadata.
- Route Nostr-based market discovery through Tor and avoid relying on clearnet relay access in normal operation.
The contributor should evaluate the available rust-bitcoin/bip324 crate surface and determine the cleanest integration strategy. The exact module layout, handshake wiring, framing strategy, identity-binding mechanism, and Nostr-over-Tor relay strategy should be designed during implementation rather than copied from a fixed recipe.
Scope
In scope:
- maker/taker encrypted transport
- peer identity authentication in v1
- transport support for both legacy and taproot flows
- encrypted maker offer discovery connections
- Tor-routed Nostr-based market discovery
- relay-selection strategy for privacy-preserving Nostr communication over Tor
- config and migration behavior needed to make encrypted transport the default
- tests for successful operation and failure cases
Out of scope for the initial project:
- wallet-at-rest encryption
- redesigning the Coinswap application protocol
- broad async/networking refactors unrelated to transport
- maker RPC transport unless there is a strong reason to include it later
Key Requirements
The implementation should satisfy these project-level requirements:
- Encryption must be the default standard, not an optional extra.
- Plaintext fallback must not be allowed in production.
- Peer identity authentication is required in v1.
- One common transport layer should support both protocol families.
- Existing application-level message types and state machines should change as little as possible.
- Transport failures should fail closed where security policy requires it.
- Nostr-based market discovery should use Tor in normal operation.
- The system should move toward eliminating clearnet communication from normal operation.
Major Things To Keep In Mind
- Keep the transport layer separate from business logic. The swap protocol should not need major redesign just to gain encrypted transport.
- Preserve compatibility across legacy and taproot flows through one shared interface, not two unrelated implementations.
- Treat Tor as complementary privacy infrastructure, not as a substitute for authenticated encryption.
- Offer discovery matters too. Metadata protection is not only about the later swap-session messages.
- Nostr market discovery is part of the privacy surface and should be treated as such.
- Relay choice matters. The implementer should identify Tor-reachable relays that are good enough for the project’s privacy goals, with preference for ephemeral relays that minimize retention and do not keep logs where possible.
- Identity binding is part of the project, not a future nice-to-have.
- Be careful about accidental plaintext paths, mixed-mode behavior, and downgrade opportunities.
- Avoid leaking sensitive metadata before encryption starts.
- Keep the design maintainable. Security-sensitive code should be isolated, understandable, and testable.
Deliverables
- A concise design note describing the chosen
rust-bitcoin/bip324integration strategy - Encrypted transport integrated into the relevant Coinswap networking paths
- Tor-based Nostr market-discovery integration, including relay-selection rationale
- Configuration behavior that makes secure transport the normal/default mode
- Tests covering happy-path operation, mismatch/failure cases, and regression risk
- Documentation for operators or developers who need to understand the new transport behavior
Evaluation Criteria
Work on this project should be judged primarily on:
- correctness and safety of the transport design
- clean integration with the existing codebase
- how well peer authentication is handled
- resistance to downgrade or accidental plaintext behavior
- how effectively the design reduces or removes clearnet communication
- how well Nostr-over-Tor discovery fits the overall privacy model
- quality of tests and failure-mode handling
- clarity of the final documentation
Open Technical Question
One important technical question remains for the implementer to resolve during the project:
- Which parts of the
rust-bitcoin/bip324crate are stable and usable enough to build the transport cleanly without unnecessary forking or excessive coupling?
This is intentionally left open because exploring the crate surface and selecting the right integration path is part of the project.