# Monero Outreach Article

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

> Some technical background: [...] But given a hash result, there is no good way to find a preimage that generates it.

Great! It's really the security of a hash function (not formally but in practice yes)

> Combining a hashlock and a timelock gives what is called a hashed timelock _contract_

HTLC, I think the 'contract' is important

## Atomic Swaps for Two Bitcoin-Like Cryptocurrencies

> 3. [...] but this hashed timelock _contract_ times out [...]

Same for contract

On this chapter in general: you explain well the hash and timelock part, to be secure each transaction need to be signed with the counterparty key; so I cannot buy my own Bitcoin and get his Litecoin at the same time because I generated the hash preimage.

- I set the hashed timelock contract with the hash I know the preimage AND the stranger public key for my Bitcoin
- The stranger set the Litecoin HTLC with the same hash AND my public key

## Background II

> and the Edwards-curve Digital Signature Algorithm (EdDSA) method used by Monero

Monero currently uses **CLSAG** an it is **NOT EdDSA**, what I can tell you is it's not precise and correct, could give you the difference as Sarang or others would (I can overall but I didn't design the signature scheme).

If I explain a bit more: EdDSA is a 'standard' signature scheme, as ECDSA and Schnorr, CLSAG include the concept of Ring Signature, where you hide the signatory in a "Ring" or set of potential signatory, this is the first point; then you have the concept of "linkability", ('L' in CLSAG IIRC) where you cannot "double spend" outputs (very short and high level explanation of CLSAG, again Sarang and others are the right people for that).

By the way: this (CLSAG, previously MLSAG, and potentially Triptych in future) makes adaptor signature on Monero non-trivial (not impossible but harder).

> This multiplication is a one-way function that is easy to calculate, but transcendently hard to reverse through division.

This is called the "discrete logarithm problem", https://en.wikipedia.org/wiki/Discrete_logarithm

May be overkill but as it is the root of many things in this protocol I stress it (I see know that you're using it latter.)

> Fig 1 signature scheme

The 'validation' calculation take the public key, the message, and the signature to check if correct or not

> Fig 2 adaptor signature

More something like this:

  Private key ----> EC calc. ------> Public key -> distribute
                                                         ^
  Adaptor key ----> EC calc. ------> Adaptor Public key -'

                 --------------                  -----> shared with the stranger
  Message -----> | Encrypt    |                 |
  Private key -> | signature  | -> Adaptor signature -> can be validated with msg,
  Adapt. Pubkey> |            |        |                Pubkey and adaptor pubkey
                 --------------        |
                  |                    ----------> *recover Adaptor privkey*
                  |   ---------------------           ^
                  --> | decrypt or adapt  |           |
  Adaptor key ------> | the signature     | --> signature -> can be validated with
                      ---------------------                  msg and public key;
                                                             broadcasted on-chain
                                                             with the transaction

The goal is to create a encrypted signature, it must be valid, and be able to validate for

- the signed message
- the base public key (the key used in the previous signature scheme)
- the encrypting/adaptor public key (the one you will reveal)

When you know both, as it is already explained

- you extract the private adaptor key,
- but not the base public key, otherwise it's broken, as you can resign without the adaptor and spend money differently

> [...] For historical reasons, this common divisor is called a discrete logarithm. [...]

What historical reasons ;) the maths science :p

> Fig. 3 zkp

Maybe Pubkey _in EC_ A and _in EC_ B (or _on EC_, don't know what is the most correct).

# Monero Atomic Swaps Concept

> As a response to way 2)

The swaplock script does not use anymore a hashlock, as it is not necessary. The swaplock script always had a 2-of-2 Bitcoin multi sig (on-chain, in the script). Before it was: haslock + 2-of-2 multisig, but the hashlock can be removed and one of the signature of the 2-of-2 is shared latter instead of the preimage (COMIT people pointed that out for ref.)

So preimage -> one of the two 2-of-2 signature (more precise: the one that is NOT used as the adaptor signature)

What you describe is correct regarding the paper, what I describe is the way it is in Farcaster RFCs.

# Monero Atomic Swaps Details

> 4. You create a (random, secret) large number, cryptographically hash it, and share the hash with the stranger.

You can then remove this

# Implementation

> Monero’s Community Crowdfunding System (CSS) [8] and is expected to finish mid 2021

I cannot ask for removing the "mid" of 2021, but it is really hard to know if all the cryptographic libraries will be ready AND reviewed to be used by public. Not saying it will not be in 2021, but maybe not mid

> The COMIT team, which previously implement Grin-to-Bitcoin atomic swaps is also developing a software implementation for Monero-to-Bitcoin atomic swaps. Their algorithms are similar to that used by Farcaster [11], with some modifications.

Currently the differences are so technical that we can say, in my opinion, that it IS the same protocol, they haven't done any changes to the logic (if we include the removal of the hashlock)

They have posted a document to adapt the protocol so Monero can be locked first, but it's work in progress and we found some problems that might require hard fork in Monero, so not really practical yet.

# Footnotes

I'm not sure how much these two footnotes improves the document, the signature example is very conceptual but not that straight forward to follow and the FN2 does not clarify too much, as it's a "technical detail", an important one but then many others should be mentionned and it blows up