delvingbitcoin
Who will run the CoinJoin coordinators?
Posted on: September 20, 2024 22:46 UTC
Joinmarket has evolved its approach to addressing the issue of communication coordination centralization in coinjoin implementations.
Initially, it utilized a single IRC server for central communication coordination but encrypted end-to-end private information between makers and takers using a Diffie-Hellman key exchange, leveraging libsodium for encryption. This method, while protecting against certain types of censorship relevant to coinjoins, such as the selection of specific utxos, was still highly susceptible to censorship due to its reliance on a single server.
To enhance robustness and resistance to censorship, Joinmarket expanded its infrastructure to include multiple redundant IRC servers. This redundancy meant that all messages were passed across all connected servers, significantly improving the system's resilience. The implementation included security measures like signatures over endpoints and communication servers to guard against replay attacks across different messaging channels. At this stage, approximately 6-8 IRC servers were typically in use, though often only three were active simultaneously. This setup required ephemeral public key identities for signing, which were generated using secp256k1. Additionally, onion endpoints for the IRC servers were used to further secure communications.
Further developments in Joinmarket's model introduced "directory nodes," which advanced the system by enabling peer-to-peer encrypted messaging between parties, thereby bypassing the need for a central message coordinator. This model was especially advantageous for the taker/maker dynamic, allowing makers—who are always online—to run their own onion services. This innovation led to larger coinjoins and more efficient messaging, moving beyond the limitations of IRC servers. However, the directory node model eventually encountered operational challenges, particularly with the functioning of onion services, leading to potential issues around nine months after its introduction.
The discussion also touches on the potential integration of nostr as an additional redundant message channel within Joinmarket's framework, suggesting this could enhance the system without significant difficulty. However, the effectiveness of using multiple nostr relays compared to redundant IRC servers, particularly in terms of performance and anonymity, remains an area for further exploration and understanding.