• strict encoding
• lightning encoding
• bitcoin::hashes::hex::FromHex
• bitcoin::bitcoin_hashes::Hash
• serde::Serialize/Deserialize

Bip44 proposes the Registered coin types which are defined in slip44

Of interest:

We should distinguish the testnets for the encoding

The following cryptographic material needs to be strict encoded:

spend: Ac::PublicKey,
view: Ac::PrivateKey,
proof: Proof<Ar, Ac>,

On functions recover_accordant_assets the current returned type is the arb secret key type but should be the acc secret key type, the conversion between the two types should be handled internally and not externally.

swap0-cli info

returns

swaps:
  - "0xc706…17db"

To query info about a specific swap, swap-cli needs complete SwapId to make the call

We have Version in PublicOffer that may handle features at the 'node' level but we also need per blockchain features. Example is Bitcoin with its variation between ECDSA, Taproot, etc.

Add a {Bitcoin,Monero}FundingInfo struct that implements serde and consensus encode, with the following fields: amount, swap_id, address.

This should use the inner Bitcoin Amount from string implementation.

Roles implements recover_accordant_assets, which in reality returns the secret key recovered

e.g.

impl From<farcaster_core::blockchain::Network> for monero::Network {
    fn from(network: farcaster_core::blockchain::Network) -> Self {
        match network {
            blockchain::Network::Mainnet => monero::Network::Mainnet,
            blockchain::Network::Testnet => monero::Network::Stagenet,
            blockchain::Network::Local => monero::Network::Mainnet,
        }
    }
}

FeePolitic must implement FromStr to be injected as arguments in farcaster-node.

Some types have been defined as u16 value in the RFC but are serialized into u8 in the code.

SatPerVByte::from_str should take float satoshi/vByte, not integer

farcaster-project/farcaster-node#4 (comment)

trait From<bitcoin::Network> is not implemented for farcaster_core::blockchain::Network

Create a struct Range in the enum FeeStategy, ensure the min and max and bounds inclusivity is correct. Impl Copy on FeeStrategy

Maker and Taker are trade roles, not negotiation roles

maker adds volume to order book, taker removes volume from order book

merging Coin with the constructs used in core would also be appreciated

Originally posted by @zkao in farcaster-project/farcaster-node#230 (comment)

core does not offer swap_id

Add more possible ways to parse Network enum from string.

Remove the serde feature, require traits on associated types and implement for all struct serialization and deserialization.

Serde is used in the node to display data in yaml format, having serde on all user facing structure is necessary.

farcaster_core errors that should be "native" to the node, must implement Clone

The node uses display for logging at trace/debug/info level, thus info to be logged should comply with Display trait

Examples:

https://github.com/farcaster-project/farcaster-node/blob/97ba0e0ff324c4b5ac3a9f18dd572da798a149e3/src/rpc/request.rs#L67

or

https://github.com/farcaster-project/farcaster-node/blob/97ba0e0ff324c4b5ac3a9f18dd572da798a149e3/src/rpc/request.rs#L309

to disambiguating from Txid from rust-bitcoin

Used for routing

Currently only Debug is implemented on Offer.

is that : deliberate? i think it will annoy the hacky parsers people will built

Node arguments should take generic types as parameters, timelocks should be constructible from u32.

Needed for SwapInfo in the node

FeePolitic::Aggressive => Priority::Low
FeePolitic::Conservative => Priority::High

disambiguates asset from amount of assets

Add the LICENSE file and see if we want to add headers in src files.

bitcoin::Amount is wrapped in core, not monero

Make TxLabel Display impl print:

Lock -> Arbitrating Lock
AccLock -> Accordant Lock

Usage: in node logs and to make sure which lock is about

This should allow the same offer to have different ID each seconds, this is a temporary fix. The offer should evolve more later.

inet2_addr

for later, to reduce dependencies

An adapted adaptor signature is not obviously and adapted signature, as an adapted signature could also be an adaptor signature

That is a confusing notation

Replace key types with bitcoin::secp256k1 types instead of bitcoin wrapped version that contains network and compress attributes, those attributes are unnecessary and at the wrong place.