Mapping of RFCs to M1 deliverables

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.

DONE A.1 User-facing [35% of M1] [2 weeks]

• Specify swap-daemon's outer API layer of user interaction (swap-clients & counterparty swap-daemon) first to guide design of inner dependencies (swap-lib & chain-syncer) to match desired UX. This includes protocol messages exchanged between swap participants, that is: interactions with the counterparty swap-daemon.

RFC: 02. User Stories contains a mockup of user interaction in a swap both via a GUI and a CLI, and also both from maker and taker perspectives. The individual steps of the user interaction throughout a swap are linked back to the relevant protocol messages of the API specified in RFC: 04. Protocol Messages.

• ENHANCEMENT: link user stories not only to inter-daemon messages, but also client<->daemon messages

• Specify the API that swap-cli and swap-gui consume from swap-daemon.

swap-cli and swap-gui consume the same interface specified in > RFC: 06. Datum & Instructions

• Specify the networking stack between swap-daemon and: swap-daemon counterparty and swap-clients.

RFC: 03. Farcaster Architecture provides a detailed overview of component interactions. The networking messages between counterparty daemons are specified down to the TLV level in RFC: 04. Protocol Messages. The networking messages between swap-daemon and swap-clients are specified down to the TLV level in RFC: 06. Datum & Instructions

DONE A.2 Service internals [16.25% of M1] [1 week]

Specify links between swap-daemon and the other deliverables it requires to facilitate a swap, but that are not user-facing, i.e. swap-lib and chain-syncers:

• Specify the subset of swap-lib's API strictly required for swap-daemon's operation swap-lib has to provide swap-daemon with cryptographic primitives, transaction construction and parsing, and a recovery mechanism for an interrupted swap.

Covered by the more encompassing requirements of M1.B.1
The cryptographic primitives swap-lib has to provide to swap-daemon are specified in [RFC: 07. Cryptographic Setup]
The transactions involved in a swap are specified in RFC: 08. Transactions
Recovery from an interrupted swap is specified in RFC: 09. Swap State

• Specify API and network stack for swap-daemon's required calls to chain-syncers

Both are included and described in the more encompassing specifation of M1.C

B. Specification of swap-lib (core protocol)

Detailed description and specification of all the libraries that, in conjunction, form swap-lib, including stateless transaction construction libraries, crypto-libraries and their wrappers, and state-machine libraries for executing the protocol.

DONE B.1 External specification of swap-lib [16.25% of M1] [1 week]

• Specify swap-lib's public API to be consumed by swap-daemon only.
  Preliminarily, covers InitTx(), VrfyTx(), Vrfy(), and EncVrfy() from the whitepaper.

RFC: 07. Cryptographic Setup: Adaptor Signatures specifies Vrfy(), EncVrfy() scripts for both Taproot and ECDSA. The script structures of transactions (for InitTx() and VrfyTx()) are specified in RFC: 08. Transactions.

• Specify swap-lib's public API to be consumed by swap-clients only.
  Preliminarily, covers Sign(), EncSign(), DecSig(), RecKey(), and Rec() from the whitepaper.

RFC: 07. Cryptographic Setup: Signatures specifies the constraints on Sign()
RFC: 07. Cryptographic Setup: Adaptor Signatures specifies EncSig(), DecSig() and Rec() scripts, both for ECDSA and Taproot.

• Specify swap-lib's public API to be consumed by both swap-daemon and swap-clients.

swap-clients also verify transaction validity before signing, so use the same verification functions exposed to the daemon.

Relevant RFCs:
RFC: 07. Cryptographic Setup
RFC: 08. Transactions
RFC: 09. Swap State

DONE B.2 Internal specification of swap-lib [16.25% of M1] [1 week]

• Specify internal function calls of swap-lib.

RFC: 07. Cryptographic Setup specifies the cryptographic functions called to satisfy the API exposed to swap-daemon and swap-client.

• Specify a concrete implementation to support a chain, including all cryptographic primitives that must be supported.

Cryptographic primitives are described in RFC: 07. Cryptographic Setup, while RFC: 08. Transactions covers the transactions necessary for a swap

DONE C. Specification of chain-syncer [16.25% of M1] [1 week]

• Specify the functionality and interface chain-syncer has to expose in order to permit the swap-daemon to carry out swaps. Describe what jobs are, and what jobs must be supported.

Jobs have been renamed to tasks, and are described in RFC: 05. Tasks & Blockchain Events

• Specify the networking stack between swap-daemon and chain-syncers.

RFC: 03. Farcaster Architecture
The networking messages between swap-daemon and chain-syncers are specified down to the TLV level in RFC: 05. Tasks & Blockchain Events

Proposed changes & concrete design choices

Taproot

The specifications target Taproot and as such require integration of Taproot into Bitcoin. As reported in our December update, the plan is to add ECDSA support only if Taproot is not integrated by the time Farcaster would otherwise be ready to be used with mainnet Bitcoin. Hopefully, Russel O'Connor's speedy trial will find agreement.

LNP-BP

The technological choice to build atop LNP-BP has impacted design of the library immensely.
Our January update delves into the motivation for this integration, and we address some of the concerns with it in the comment section.
We have forked the lnp-node here and started integration work.