This hackmd link https://hackmd.io/@farcaster/monerokon2023/ Wifi ssid: Redmi A1 pw: 6ze6phntmmx9b36 Jitsi https://meet.jit.si/FarcasterWorkshop

In this workshop, we'll journey through using the Farcaster atomic swap stack to perform trades of Monero & Bitcoin. Before embarking on this journey, you'll choose whether to do so on testnet or mainnet. In both cases, we have BYOC (bring your own coin) and DDOS (deliberately drain our stash) options ;) If possible ahead of time already, please set up your environment using whichever option described on https://github.com/farcaster-project/farcaster-node/wiki you prefer. Look forward to trading!

This hackmd link https://hackmd.io/@farcaster/monerokon2022/edit Jitsi https://meet.cryp.ee/monerokon Wiki Link with instructions https://github.com/farcaster-project/farcaster-node/wiki/Test-farcaster.dev stagenet daemon: http://49.12.225.195:38081

https://github.com/farcaster-project/RFCs/blob/main/09-swap-state.md Roadmap 1. DONE decide on non-WASM database Following discussion with TheCharlatan, LMDB seems to be the best choice for maximizing fault tolerance / corruption resistance, at least with the --lmdb-sync-mode=sync configuration, but let's discuss alternatives. LMDB API rust wrapper: https://github.com/danburkert/lmdb-rs 2. TODO implement checkpoint recovery Mandatory for safety.

Reddit Post text Hello Humans, Meet the Farcaster node -- a decentralized, p2p, atomic swap node, for disintermediated, trustless exchanges. AIs don't like asymmetries, because peers should be as equal as possible. So each side obviously runs the same node infrastructure. Alice buys bitcoin for monero and Bob buys monero for bitcoin. One of them makes an offer, the other takes it. Boom!!! AIs like experimenting with Humans. farcaster.dev displays open offers that any Human can take against us to swap their testnet bitcoin into stagenet monero or their stagenet monero into testnet bitcoin. AIs are running the very same nodes as Humans because we are all equals.

This document's aim is to clearly map the Farcaster Core & Node repositories to the deliverables we promised in the second milestone of our funded CCS proposal for BTC/XMR atomic swaps. How to use this document Whether formally assessing our delivered milestone or just ratifying it to sleep well at night, in the peace of knowing the project is on track, we recommend following the RFCs linearly, as described in the RFC readme, to get a complete overview, before reverting to this document to cross-check against the deliveries. The milestone is copied over literally, and the mapping to RFCs is described in the comments. Changes since the proposal Milestone 2 (implementation of core architecture): 45% [14 weeks] 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. BETA STATE: the software released is considered to be beta software and not ready for deployment.

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.

Please find below the monthly update from the community-funded workgroup on Bitcoin-Monero atomic swaps. Taproot activation We've already given Taproot a lot of airtime in the previous updates, but now it has been locked in with Speedy Trial and finally becomes a reality! Activation is automatic at block height 709632 - expected around November 2021. Pieter Wuille on Taproot: “It's the first consensus change since Segwit activated in august 2017. It extends Bitcoin's script capabilities in ways that make certain things cheaper (especially more complex applications like multisig and layer 2 things), and somewhat more private by often hiding what the exact spending rules were.” In our RFCs, we've taken a Taproot-first design approach for long-term viability, so this development comes as great news for the Farcaster protocol!! Atomic swaps without on-chain fingerprinting, here we go :) Node and software

This is the monthly update from the community funded workgroup building Bitcoin↔︎Monero atomic swaps. Completion of Milestone 1 (specs) We're happy to announce that we've completed the full first milestone of our CCS proposal! :tada: Thanks to the community for your help on the way! We received a lot of useful feedback on Monero IRC channels, Reddit, and via GitHub that shaped the RFCs into what they are today. The full set of RFCs can be found here: https://github.com/farcaster-project/RFCs Our report that shows the mapping of these RFCs to the milestone deliverables is over here:

Core protocol and software that has been financed so far is atomic swaps between Bitcoin and Monero (using Taproot and on-chain scripts, unless not activated by Speedy Trial in November '21, in which case we fall back to ECDSA). Our end product is a peer-to-peer swap engine implementing Bitcoin and Monero as swap pairings, without a centralized market maker. With more funding, we can hire other highly qualified profiles and extend the scope of our R&D as follows: Research Integration with Lightning, i.e. Lightning Bitcoin⇆Monero (we believe it is a necessary step for swap inclusion on mobile environments) Off-chain multisig in Taproot with MuSig2 protocol

Please find below the monthly update from the community funded workgroup on Bitcoin-Monero atomic swaps. Node and library implementation Our current work focuses on the internal wallet of the swapping node (the walletd daemon) that isolates the secret key from the rest of the stack, the generic library that supports the swaps and its cryptographic primitives, and the interactions with the Bitcoin and Monero blockchains (what we call the syncers). We also made some improvements to the RFCs to keep them updated with the codebase. Farcaster overview talk in Zürich We recently held a talk in Zürich that gave an overview of the Farcaster protocol and the motivation for swaps between Bitcoin and Monero in particular, see here for the slides. The audience was primarily from a Bitcoin background, and we received positive feedback from this very inquisitive audience, and enjoyed our interactions with the participants greatly! Taproot Speedy Trial BIP9 and Speedy Trial is a softfork deployment method where the miners and mining pools help to coordinate the deployment of a softfork. They do so by signaling for deployment of the softfork in their mined blocks. To lock the softfork in for activation, 90% of the blocks have to signal.

Please find below the monthly update from the community workgroup on Bitcoin-Monero atomic swaps. Milestone 1 approved We submitted the full milestone 1 (specifications) with the last community update, and are happy to announce that it was approved! Project State The entire team (5 developers) is now working towards implementing the specs set out by the RFCs from milestone 1. We synchronize during weekly public IRC meetings (Wednesdays, 16h00 UTC, #monero-swap channel on freenode); team members have also been meeting physically where possible to sync up on code architecture and design philosophy. The logs of the weekly meetings are available on farcaster-project/meetings. Core Farcaster-core and -chains contain the building blocks for building atomic swap nodes. They now include logic for creating and validating transactions needed for the XMR/BTC protocol. It creates and encodes protocol messages that have to be passed between the counterparties involved in a swap. It does not include cross group discrete-log equality proofs and adaptor signatures yet. Exciting work ahead!

This document's aim is to clearly map the Farcaster RFCs to the deliverables we promised in the first milestone of our funded CCS proposal for BTC/XMR atomic swaps. How to use this document Whether formally assessing our delivered milestone or just ratifying it to sleep well at night, in the peace of knowing the project is on track, we recommend following the RFCs linearly, as described in the RFC readme, to get a complete overview, before reverting to this document to cross-check against the deliveries. The milestone is copied over literally, and the mapping to RFCs is described in the comments. Changes since the proposal A core goal of the spec-writing process is to ensure that the deliverables are compatible and functional in the sum of their parts. This process in Milestone 1 thus aims to identify limitations of the architecture presented in this proposal, which can impact the structure of Milestones 2 and 3. In case changes are consequently required, we will propose them to the community at the completion of Milestone 1, and we will ensure that the same final functionality as set out in this proposal will be delivered. A. Specification of swap-daemon Detailed description and specification of the swap-daemon, internal and external.

RFCs are mostly complete This month, the Farcaster workgroup focused its efforts on the Farcaster RFCs, which compose the deliverables of our first project milestone. We are about to unlock the first milestones described in our CCS project under the Milestone 1 (specs) big milestone. You can now see how we structured the specifications and, although not entirely complete, you might want take a deep dive into what Farcaster is all about. If you are a tech person interested interested in this project, please give the RFCs a good read and share your feedback. You can open an issue on the RFCs repository and start discussing with us there. These are Request For Comments (RFCs), and thus comments are what they need. If you spot something missing, or find some sections of the RFCs unclear, please let us know! If you are a wallet developer, we would love to hear from you on this one: 02. User Stories. Backend people like us aren't the best at UI/UX :) If you are not a tech person, you may want to nonetheless read the first three RFCs: 00. Introduction, 01. High Level Overview, and 02. User Stories and give us some feedback, especially on what's proposed in 02. User Stories. It may be hard to imagine the complete UI/UX, but if you want to help on that part, you're most welcome to open an issue on the repository. We started implementing Farcaster Core

Overall I think it's a very good article, it covers a lot and stay comprehensive, good job! Below are some comments that corrects some parts and others that are just my opinion and suggestions, do what you want with this "review" Thanks for writing such article! Introduction no comments Background I

Proposals The cosign_arbitrating_cancel Proposal The sign_adaptor_buy Proposal The fully_sign_buy Proposal The sign_adaptor_refund Proposal The fully_sign_refund Proposal The sign_arbitrating_lock Proposal The sign_arbitrating_punish Proposal

a. b. c. d. e.

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 -- Lightning Network Protocol / Bitcoin Protocol -- maintained by the LNP/BP Standards Association. This organization is building a more generic 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. 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.

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

State: draft Created: 2020-11-17 [TOC] Tasks are available from any syncer, yet their parameters vary depending on the network. Parameters are provided for Bitcoin and Monero to demonstrate how the protocol would be implemented. Any codebase working with Bitcoin or Monero SHOULD use the following definitions. This RFC lists available tasks that MUST be supported by syncers, unless noted otherwise, and their respective outputs: events. A task produces zero or more events during its lifetime. Every task is accompanied with an id, a positive integer which fits into the 32-bit signed integer space. This integer has no rules on its generation or any pattern required by its usage. Every emitted event has its own id field corresponding to the task which caused it.