--- tags: CommunityUpdate --- # Farcaster: Community update August Please find below the monthly update from the community-funded workgroup on Bitcoin-Monero atomic swaps. ## Code advancement ### Big milestone 2 close to completion We are soon to reach the big milestone 2 of our CCS proposal, which encompasses about half of the entire work to be delivered to the community. Milestone 2 deliverables include the minimal version of all the microservices (=small daemons) that form the Farcaster node. The different microservices, in orchestration, run the swaps. To quote the CCS proposal: > Minimal functionality: at completion-time of milestone 2, all components for executing atomic swaps successfully are implemented using our libraries as proposed in the presented architecture. #### What is next? The next and last milestone left to complete (number 3) is about bringing what is produced in milestone 2 to a minimal viable product (=MVP) level. ### Running the swaps Using our microservice architecture, we are mostly complete with the "happy" swap execution path, i.e. the case where the swap completes successfully and neither Alice or Bob abort the process. Lots of messages flying around and melting our brains, lots of debugging, but the tech stack is truly flexible and extensible. The daemons we have working right now: - walletd (1 in total for all swaps), - swapd (1 per swap), - peerd (1 per peer connection), - syncerd (1 per blockchain), and - farcasterd (1 in total for all swaps). These daemons are ~90% functional at the moment. ### Syncers We have now completed the necessary interfaces for communicating with both blockchains - something we termed `syncers`. The integration work in the node is mostly complete. For bitcoin, we are currently using the electrum protocol, while for monero we are communicating with the monero daemon and monero-wallet-rpc. Using the monero-wallet-rpc for multiple swaps at a time proved quite slow during our testing, so we are now exploring the usage of vtnerd's [`monero light wallet server`](https://github.com/vtnerd/monero-lws). In contrast to the monero-wallet-rpc, the light wallet server can keep track of and scan for transactions of multiple distinct view keys at a time. Our work integrating the monero rpc interfaces also led to some pull requests to [`monero-rpc-rs`](https://github.com/monero-ecosystem/monero-rpc-rs) in the monero-ecosystem project. Additionally, [`monero-rs`](https://github.com/monero-rs/monero-rs) and [`rust-internet2`](https://github.com/internet2-org/rust-internet2)'s new upstream releases include our PRs needed for Farcaster :) ### Farcaster core `farcaster-core` is now a public library in the [crates.io repository](https://crates.io/crates/farcaster_core). Want to learn more about it? Please, check out [its documentation](https://docs.rs/farcaster_core/0.1.0/farcaster_core/). ### Outlook With all the components coming together, we are shifting our attention towards testing and refactoring. Our goal is to have a functional test suite that can simulate all possible events and paths in the protocol - this will decrease the risk of unexpected scenarios once our swap protocol hits the road :) ## FAQs You might have seen quite a few news on Reddit about Monero atomic swaps recently, and a lot of hype surrounding it. Here are comments on questions we are getting asked repeatedly. ### Are atomic swaps ready for real-world usage? We know this is not a sexy thing to say, but if hype and expectations don't match reality, end users do get burnt. This is brand new tech, and if you're using it at this stage, it is because you want to test it out and help bugs get ironed out, and that does mean potentially sacrificing funds to the crypto gods, and you should be ok with that, if you're willing to test it using main chain funds. ### COMIT and Farcaster: Native interoperability for the win We are excited to see the sector using native interoperability with atomic swaps moving forward. COMIT people are technically very capable, and we admire their work, but they are NOT our competitors as many consider, they're using and promoting our tech (that is truly flattering), producing open-source software, steering the field to where we want it to be, and we surely love that. Our competitors are the non-native interop solutions, which we consider long-term inferior tech, but as you might know, inferior tech sometimes dominates the market :( And that is what COMIT and Farcaster must beat. <!--_COMIT and Farcaster use the same protocol_--> ### Do COMIT and Farcaster use the different protocols? When reading some comments it is not clear for everyone that COMIT and Farcaster are based on the same protocol, literally, the same concept and the same transaction structure are used in both implementations. COMIT did improve the protocol published originally, and we genuinely commend them for their great work, but in practice, the core protocol is the same and shares the same advantages and limitations. <!--_transaction chaining in Monero -> same protocol, no need for xmr tx chaining_--> ### Is transaction chaining necessary for Farcaster or COMIT atomic swaps? No, it is NOT necessary to have transaction chaining on the Monero side. COMIT comments that service providers selling BTC for XMR is not possible without transaction chaining, because a malicious Alice buying BTC for XMR can get Bob to lock his BTC first, and then Alice simply does not lock its XMR, and forces Bob to waste money in transaction fees to get his BTC refund back. In the new protocol COMIT proposes Monero is locked first (and this does require the transaction chaining and thus breaking changes to Monero), but it does not solve the problem theoretically (now the attack is in the other direction), but practically it reduces the costs required for refunding as XMR fees are cheaper. Nonetheless, there are other practical mitigations to this very problem that are possible. Node reputation being one of them, that although we dislike it, it is practical. Layer 1 atomic locks (=two lock transactions become valid at the same time) are not possible, because they're susceptible to double-spend attempts (there is no money locked on-chain, and thus nothing to lose on the attack). But layer 2 atomic locks are possible (since there is already money locked on-chain), and that may be the very long-term solution, and that does require transaction chaining in Monero, among other requirements. #### In sum, what would transaction chaining enable? Having this would allow a new class of protocols to work on Monero, namely protocols requiring spending unmined transactions off-chain, which may be seen as the backbone for layer 2 protocols in Monero. However, that is not all that is needed for that, but a prerequisite. That would allow new atomic swap and payment channel protocols to evolve, that's why research and discussions have increased recently, and we fully support it. But again we don't need it, not right now! ### Farcaster is NOT dependent on Taproot: Bitcoin BIPs 340, 341 and 342 Schnorr signatures and Taproot are not needed for the Bitcoin side to make the atomic swap work using Farcaster. But we can achieve privacy and quality assurances by using Schnorr. And our farcaster-core library takes that into account. Let us do a little recap. <!--_but xmr tx chaining would allow more for xmr, but that's another story_--> ### Design decisions for supporting different cryptography As you might know, Bitcoin currently uses ECDSA for its signatures and will enable Schnorr before the end of the year. We considered this when developing our libraries, and designed the API such that we can switch to another cryptography in a straightforward way. These are the schemes we're trying to support: - ECDSA Adaptor Signature: that's what COMIT and Farcaster use for the moment. It is the easiest to implement, nonetheless, it uses non-audited, experimental crypto libraries. - Schnorr Adaptor Signature: that's what we want to implement soon, it is an on-chain multisig. It is better suited for the task, the math is simple, and we can achieve constant-timeness and other quality assurances, and most importantly it is easier to get peer-reviewed, audited code. - Schnorr Adaptor Signature with the MuSig2 protocol: MuSig2 is an off-chain multi-signature protocol, like the one used in Monero, it allows multiple participants to generate cooperatively one signature, and that's our ultimate goal. ## Thank you! Would you like to contact us? Please reach out at `#monero-swap` on Libera.chat. We also have a dev meetings every Wednesday at 12pm UTC for about an hour, feel free to join. The Farcaster workgroup [[1] Bitcoin-Monero Cross-chain Atomic Swap (IACR)](https://eprint.iacr.org/2020/1126) [[2] Atomic Swaps between Bitcoin and Monero (arXiv)](https://arxiv.org/abs/2101.12332) [[3] Monero Atomic Swaps implementation funding CCS](https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-implementation.html)