Farcaster: Community update December

--- tags: CommunityUpdate --- # Farcaster: Community update December It's been a month since work slowly started on the Atomic swap project, codename Farcaster. We are currently working on writing some RFCs to get a crystal clear picture of what we have to build: the constituent components and their interactions. Nonetheless a couple of open, applied-research questions are continuously popping up, and we're slowly tackling them and catching up with an ever evolving crypto ecosystem. ## Bitcoin bips 340-342: Schnorr and Taproot I rubbed the lamp with a B on it, and a bitcoin-genie jumped out of the lamp and decreed: > My advice would be to implement stuff using Schnorr, and if you somehow run out of work to do, back up and start on ECDSA Following that advice, we invested time on working out how to use Taproot outputs and Schnorr signatures -- an upgrade from segwit v0 outputs as originally described on the paper. That improves privacy of the swaps: in the most common swap outcome -- the successful case -- no script, nor the existence of a script hidden behind that pubkey, will ever be revealed to the Bitcoin blockchain, and makes Bitcoin transactions cheaper. Beat that! For more details, visit [here](https://github.com/farcaster-project/RFCs/blob/hackmd/transactions.md). Another benefit: Schnorr adaptor signatures are simple, and easy to get to production-level, audited code -- that is harder to accomplish using ECDSA adaptor signatures. That said, the genie's wild prediction for Schnorr/Taproot softfork activation on bitcoin is "Q4 2021". These changes will influence our list of deliverables: possibly no ECDSA, but instead Schnorr signatures -- before it was only ECDSA signatures. ## Don't leak that key now! We worked on the temporal safety of publishing Bitcoin transactions. Just by publishing some of them, secret keys are leaked, so we must be sure we're within the temporal safety margins before publishing each transaction. More details [here](https://github.com/farcaster-project/RFCs/blob/hackmd/tx_timesafety.md). Knowing when to broadcast a transaction is essential, however one also have to make sure the transaction will go through within the safety window, for that we invested some time on RBF (Replace By Fee) and we will soon draft the prerequisite in the RFCs. ## The chain-syncer and its tasks The chain-syncers synchronize the protocol universe to the blockchains universes, its the interface of contact to the external world. It receives tasks from the daemon such as watch for funds or transactions, or broadcast transactions. Those tasks will produce blockchain events, consumed by the daemon executing the protocol. This work can be found [here](https://github.com/farcaster-project/RFCs/blob/hackmd/jobs.md). ## Daemon's protocol state and runtime A general introduction to Farcaster's architecture can be found [here.](https://github.com/farcaster-project/RFCs/blob/hackmd/architecture.md) In our distributed architecture, the Swap-Daemon is the hub that receives messages coming from every direction: in the form of client instructions, blockchain events, etc. It contains the runtime environment where the swap protocol is executed. The atomic-swap is a cryptographic/game-theoretical protocol, where most of the handled events are offchain. Yes, it settles onchain, but most of the hot action is offchain. We worked on mechanisms on how to evaluate the protocol into a given protocol state or how to recover from a failure to that given state safely (without putting funds at risk) -- and do so consistently, by computing the protocol state from event-logs. Pure functional-programming magic helps here. Find more details [here](https://github.com/farcaster-project/RFCs/blob/hackmd/state_runtime.md). Additionally we started work on the daemon's protocol execution runtime -- where mathematical constraints meet runtime. ## User-stories and Client One day, not too far in the future, you might want to try the software. We devised the simplest use case possible to inform our Client API. We distinguish two phases: the negotiation phase and the swap phase. During the negotiation phase two roles are available: the Maker and the Taker. A maker will produce an offer and start his node in advance, waiting for a connection. A taker will then be able to connect to the node described in the offer. The swap phase can now start. During the swap phase, each participant, at their turn, will be able to send their amount to an address specified by the swap client. After enough confirmation on the locked funds, the swap will happen on-chain and each participant will receive their money. Find this work [here.](https://github.com/farcaster-project/RFCs/blob/hackmd/user-stories.md) ## Community help We are not the most talented people to produce visually appealing things, we know that! Do you feel bored? Do you love this community? Do you have a bit of time and the right skills? Come over and give us a hand! ### Logo Farcaster is a portal across universes. Can you draw a minimalistic logo for this project? ### Website Additionally, we got https://farcaster.dev domain name, and could use community help to do something nice there. ## 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. ### Monthly community update We have a monthly non-technical progress update to inform the community about our progress. This is our first one, we hope you like it! Please reach out to us if you have any improvement suggestions :) That is all for this update, we're are so proud of being part of and funded by this amazing community; thank you all!