Farcaster: Community update January

--- tags: CommunityUpdate --- # Farcaster: Community update January ## Streamline via LNP/BP architecture We ran an in situ CCC event in the last week of December. A participant brought to our attention the organization [LNP/BP](https://github.com/LNP-BP) -- *Lightning Network Protocol / Bitcoin Protocol* -- maintained by the LNP/BP Standards Association. This organization is building a more [generic node](https://github.com/LNP-BP/lnp-node) for running the lightning network protocol over the bitcoin protocol (LNP/BP) -- we hope you see the analogy to TCP over IP (TCP/IP) :) Nice devcall introduction on [this node](https://www.youtube.com/watch?v=TgmyO0ecVNI&t=178s). While studying that work, it became clear that their node includes all the capabilities needed for executing p2p, off-chain, game-theoretical/cryptographic protocols that settle on chain. Examples of these type of protocols are: payment/state channels, discreet log contracts and, relevant to us, atomic swaps. To achieve the required generality (they want to support several use cases), the LNP/BP devs chose a microservice architecture with many small, highly specialized daemons, which communicate with each other using message buses. This is also how large enterprises run scalable infrastructure, and a solid foundation for a P2P financial system. A node ends up defined as a cloud of microservices that can be run locally, remotely, or distributed across many machines. This kind of architecture is extremely flexible, and scalable, as one can mix and match different services or protocols at will. To clarify, we are investigating streamlining our work with a newer node designed for such activities. We are NOT discussing moving to a Lightning Bitcoin Monero setup. Rather, we are working towards making a quality project that holds better chances for long term survival. If we walk side-by-side with a Lightning node, we're more likely to be future proof. Since atomic swaps are all about interoperability, implementing popular standards greatly increases their utility. Think of the internet: a set of standardized protocols. We believe it would benefit the Monero ecosystem to stay close to the lightning node code-base. Why? - Lightning network ecosystem has been evolving organically, and standards for a lot of its plumbing were worked out and implemented by a few groups independently. A significant portion of [the standards](https://github.com/lightningnetwork/lightning-rfc) are of interest to us. Interestingly, we propose to fork from a codebase developed by a standards association. Thus, we inherit a few useful standards curated by innumerous good people for free, that might be of use to us with no to minor modifications. - It would put us a step closer to integration onto a larger, emerging P2P financial ecosystem. LN may become an important network in the future, and our node would implement, to some extent, LN standards, and may be able to communicate (but potentially be ignored) with standard LN nodes. - Larger dev community. Active upstream development/maintenance that can be incorporated -- that means, more likely to create long-lasting, living codebases. - It brings us one step closer to swapping lightning bitcoin with on-chain monero. It is our current understanding (but more research is needed) that a variant of the current swap protocol works for lightning channels based on PTLCs (*elliptic curve point time locked contracts*), but certainly not for HTLCs (*hash time locked contracts*). - A routed swap may be possible through PTLC-based nodes of the lightning network. - Unfortunately, HTLC is the standard currently being deployed in LN. That incompatibility means that payment routing through standard lightning nodes would not be supported. - On the other hand, a routed swap would be possible through nodes of the lightning network using PTLCs -- topic of active discussion, as PTLCs greatly improve Lightning in regards to [security, privacy and functionality](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html). There are no real downsides to using PTLCs instead of HTLCs, so we are optimistic that they will be the standard at some point. - With lightning swaps, an entire swap could be executed in just a few minutes, as only the Monero transaction would have to confirm on-chain. This has implications on Monero's liquidity. --- **Disclaimer 1**: This is not what we are building, but we want to present some arguments that convinced some of us that if we walk side-by-side with a lightning node, we're more likely to be future proof. Atomic swaps are all about interoperability, or, if you like, compatibility, with the largest possible number of high liquidity providing nodes in a network. The more popular standards the node implements, the more compatible it is with other nodes. That said, the plan is to be pragmatic and certainly not strive for compatibility with Lightning whatever the cost, but if and when needed, it may be feasible to improve compatibility. **Disclaimer 2**: The source code of LNP/BP node is under *heavy* development (project started in October) and is currently not fully functional, but it exposes a very flexible architecture and aims to solve problems similar to ours, in particular using similar tools as planned for Farcaster (Rust, distributed architecture using zeromq). Incorporating LNP-node would most likely not work with their project as a direct dependency, but require a fork to maintain that would contain the skeleton of the Farcaster node. --- This would close a few gaps that were out of scope for the Farcaster project, and regarding which we've been queried several times. For example, integration into a P2P network where swaps may happen. But it would also leave other issues open -- albeit closer to a resolution -- such as finding a swap partner in a P2P network, that would require new gossip messages for the network. ## musig2 adaptor signature We worked on musig2 adaptor signatures, with a focus on ensuring safe interaction between the swap participants. You can find a technical description from Jonas Nick of how adaptor signatures would work in the musig2 protocol [here](https://github.com/jonasnick/scriptless-scripts/blob/musig2/md/musig2-adaptorsig.md#correctness), but that document does not describe the safe interaction between participants, which we started working on. ## RFCs We're gluing our different RFCs to provide a cohesive structure of the ongoing specification effort over here: [Overview](https://github.com/farcaster-project/RFCs/blob/hackmd/overview.md) We have a new [inter-daemon protocol messages](https://github.com/farcaster-project/RFCs/blob/hackmd/inter-daemon-protocol-messages.md) RFC that specifies the communication API used by counterparty daemons and have updated the [User Stories / High Level Protocol](https://github.com/farcaster-project/RFCs/blob/hackmd/user-stories.md) to show how this API binds into the phases of a swap from the user perspective. The next step is fleshing out the communication API that the binaries involved in a swap (`daemon`, `client`, `syncer`) provide to one another. This should finish in February and tick off our first submilestones :checkered_flag: ## Project's transparency ### Repository We are pushing our work to: https://github.com/farcaster-project/ ### Communication channel Want to talk to us? Come meet us on freenode #monero-swap. We have a weekly meeting every Wednesday at 16:00 UTC where we share the work done and organize ourselves. Logs of past meetings can be found here: https://github.com/farcaster-project/Monero-Swap-IRC-Meetings ### Availability Past month was slow for the Farcaster workgroup, for independent, individual and personal reasons: corona baby-boom infection hit a member of the team that was on maternity leave, and two relocations -- and all the practical implications of that -- that were time- and nerve-consuming. We truly apologise for that. But we're almost back on shape. We remind you that we haven't spent any of the money from the CCS donations yet, so rest assured, we're just starting :)