docs: rfc-0241 tari-monero atomic swap #3623

SWvheerden · 2021-11-26T14:49:13Z

Description

This document adds in RFC-0241 which describe Tari Monero atomic swaps

Motivation and Context

This is required if we want to be able to do Atomic swaps between Tari and Monero.

philipr-za

Just did a brief read through so didn't dig into the math.

Main comment is after the merge of the two separate PRs there is a lot of repetition between the sections that can be improved. I would also say you should make it clear how the second approach is different and discuss the benefit of it.

RFC/src/RFC-0202_TariScriptOpcodes.md

RFC/src/RFC-0240_AtomicSwap.md

RFC/src/RFC-0241_AtomicSwapXMR.md

hansieodendaal

Hi @SWvheerden,

Really nice so far.

As discussed:

We are not using MuSig sugnatures in the RFC, but aggregated Schnorr signatures.
The math for proving x_m_a = x_a for X_m_a != X_a and x_m_b = x_b for X_m_b != X_b is not correct.
Please add the Monero transaction to the transaction flow diagram and number them to enhance referencing from the text.
Please add proving knowledge of x_m_a and x_m_b to the alternative script, i.e. we need an ed25519 scripting option similar to the Ristretto one.
Please change the lapse transaction in both scripts to be claimable by either party at any time after height_2 - add another if then else branch for height_2.
Please arrange the alternative concept to be the primary proposed concept as it is a lot simpler and based on TariScript security.

Other remarks:

Some of math the rendering are failing.
Please verify your rendered text with Grammarly; this is easily done by with the online Grammarly by analyzing the rendered text.

Thanks.

hansieodendaal

Looking really good @SWvheerden.

Just a few remaining comments I think need to be addressed.

RFC/src/RFC-0241_AtomicSwapXMR.md

hansieodendaal

LGTM - well done

RFC/src/RFC-0241_AtomicSwapXMR.md

stringhandler · 2021-12-07T10:22:49Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+Monero transaction and that everything is complete as they have agreed. If she is happy, she will provide Bob with the 
+pre-image to immediately claim the Tari UTXO.
+
+### Key security


This section can probably be removed entirely

I think it is very informative to show this for a mixed audience, even though it might seem trivial. Many people wonder why it is safe to construct an aggregated public key where their counterparty knows the other portion of the aggregated secret key.

I have made my viewpoints public above that I don't feel this contributes much to the article. We need to make a call about do we keep this or not.

Fair enough, we can keep it. Ideally it should just be somewhere else, with a link

RFC/src/RFC-0202_TariScriptOpcodes.md

RFC/src/RFC-0241_AtomicSwapXMR.md

hansieodendaal

Hi @SWvheerden, nice additions after my last review and after consideration some more comments. Thanks.

hansieodendaal · 2021-12-08T04:41:23Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+\end{aligned}
+\tag{1}
+$$
+


I think a section here called "Key equivalence across different elliptic curves" or the like is warranted, similar to how "Key construction" is explained.
This is essentially a Discrete log equivalence (DLEQ) proof and should be mentioned. Reference to the Monero article https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf and more general use for example https://projekter.aau.dk/projekter/files/260345149/Electronic_voting_application_based_on_public_verifiable_secret_sharing.pdf paragraph 5.3.1 and https://crypto.stackexchange.com/questions/60127/key-equivalence-across-different-elliptic-curves should be made, possible with a very brief one sentence summary about the differences between the two approaches.

hansieodendaal · 2021-12-08T04:49:17Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+$$
+
+
+### Commitment phase


I think it is important to mention here why a DLEQ proof is not needed and how the script (committed to in the input script signature) fulfils that role, especially to prime the audience that expects a DLEQ proof should be present.

hansieodendaal · 2021-12-08T04:50:42Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+
+Doing atomic swaps with Monero is more complicated and requires a cryptographic dance to complete as Monero does not
+implement any form of HTLC's or the like. This means that when doing an atomic swap with Monero, most of the logic will
+have to be implemented on the Tari side. Atomic swaps between Monero and bitcoin have been implemented by the [Farcaster  project](https://github.com/farcaster-project/RFCs)


Probably Bitcoin should be capitalized throughout.

philipr-za

Looking good. Just something I realized looking at this revision but I believe that Ed25519 is actually referring to the EdDSA signature scheme and we have been using it to describe the ECC private-public key cryptography. I believe it is more correct to refer to those points as Curve25519 points rather than Ed25519 points. It is arguable whether the phrase Ed25519 public key is correct or not depending on if it is referring to the public key in a signature or not but this is not always the case?

I just wanted to check that everywhere we are referring to Ed25519 we are talking about a signature rather than just a key.

RFC/src/RFC-0241_AtomicSwapXMR.md

sdbondi

Few minor corrections/notes as I was reading through this

sdbondi · 2021-12-09T06:57:23Z

RFC/src/RFC-0202_TariScriptOpcodes.md

@@ -325,6 +325,28 @@ push 0.
 Identical to [`CheckSig`](#checksigmsg), except that nothing is pushed to the stack if the signature is valid, and the
 operation fails with `VERIFY_FAILED` if the signature is invalid.

+##### ConvertToRistrettoPoint,
+
+Pop the top element, converts it to a Ristretto point, and pushes this to the stack.


It's not clear what the source element would be for this conversion. Of the stack items allowed (Number, Hash, Commitment, PublicKey, Signature) non really fit as inputs to this op, are you proposing a 32-byte blob or would this be a conversion from PublicKey? Hash is 32 bytes but I would say it isn't appropriate for this use.

Yeah, I realized this, and for now, the script mentions Hash as it can be used as 32 bytes. Left his out for now till we can discuss what route we want forward with this.

The correct approach in my view would be to define a new StackItem type RistrettoScalar(RisrettoSecretKey)

Suggested change

Pop the top element, converts it to a Ristretto point, and pushes this to the stack.

Posp the top element, which must be a valid Ristretto scalar, calculates the corresponding Ristretto point and pushes this to the stack.

Ah yup that makes sense

sdbondi · 2021-12-09T07:19:48Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+Doing atomic swaps with Monero is more complicated and requires a cryptographic dance to complete as Monero does not
+implement any form of HTLC's or the like. This means that when doing an atomic swap with Monero, most of the logic will


Tari-Monero atomic swaps are significantly more involved than BTC atomic swaps as Monero does not implement scripting that allows for any form of HTLCs or similar.

RFC/src/RFC-0241_AtomicSwapXMR.md

sdbondi · 2021-12-09T07:57:07Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+refunds slower, but it should be safer in giving more time to finalize this. 
+
+Allowing both to claim the Tari after the second lock height is, on face value, a safer option. This can be done by enabling
+either party to claim the script with the lapse transaction. The counterparty can then claim the Monero. However, this


Suggested change

either party to claim the script with the lapse transaction. The counterparty can then claim the Monero. However, this

either party to claim the Tari funds with the lapse transaction. The counterparty can then claim the Monero. However, this

sdbondi · 2021-12-09T08:09:38Z

RFC/src/RFC-0241_AtomicSwapXMR.md

+### Detail
+
+This method relies purely on TariScript to enforce the exposure of the private Monero aggregate keys. Based on [Point Time Lock Contracts](https://suredbits.com/payment-points-part-1/), the script forces the spending party to supply their Monero
+private key part as input data to the script, evaluated via the operation Ed25519Point. This TariScript operation will


Suggested change

private key part as input data to the script, evaluated via the operation Ed25519Point. This TariScript operation will

private key part as input data to the script, evaluated using the `ToEd25519Point` operation. This TariScript operation will

RFC/src/RFC-0241_AtomicSwapXMR.md

CjS77

Some comments up to and not including the BTC-XTR section

CjS77 · 2021-12-09T10:45:01Z

RFC/src/RFC-0202_TariScriptOpcodes.md

@@ -325,6 +325,28 @@ push 0.
 Identical to [`CheckSig`](#checksigmsg), except that nothing is pushed to the stack if the signature is valid, and the
 operation fails with `VERIFY_FAILED` if the signature is invalid.

+##### ConvertToRistrettoPoint,
+
+Pop the top element, converts it to a Ristretto point, and pushes this to the stack.


The correct approach in my view would be to define a new StackItem type RistrettoScalar(RisrettoSecretKey)

Suggested change

Pop the top element, converts it to a Ristretto point, and pushes this to the stack.

Posp the top element, which must be a valid Ristretto scalar, calculates the corresponding Ristretto point and pushes this to the stack.

RFC/src/RFC-0202_TariScriptOpcodes.md

CjS77 · 2021-12-09T10:50:07Z

RFC/src/RFC-0240_AtomicSwap.md

@@ -48,7 +46,7 @@ technological merits of the potential system outlined herein.

 ## Goals

-The aim of this Request for Comment (RFC) is to describe how an Atomic swap will be created.
+This Request for Comment (RFC) aims to describe how an Atomic swap will be created.


created.. where? between which parties / chains?

RFC/src/RFC-0240_AtomicSwap.md

hansieodendaal

Looking really good. I especially like the discussion about Key equivalence and additional security changes to method 1; addition of the DLEQ proof, addition of the blinding factor to the Monero private key and corresponding changes to the script.

I think Key equivalence needs some grammatical and punctuation/spacing changes.

hansieodendaal

LGTM

stringhandler

The RFCs are still in draft anyway, so I don't mind merging this, but before I do, I would like the following:

Add a link to the Github discussion about RFC 0241
Remove the changes to RFC 0202 and rather mention that a new opcode must be created in RFC 0241. The changes to 0202 can be split into a new PR for future tracking

SWvheerden · 2022-01-10T06:49:34Z

Moved the changes to TariScript to #3686

Co-authored-by: Stan Bondi <sdbondi@users.noreply.github.com> Co-authored-by: Philip Robinson <simian@tari.com>

philipr-za

I think we are ready to merge this RFC and we will discuss further via the Discussion and chat channels.

Changes have been made

philipr-za changed the title ~~docs: Tari Monero atomic swap~~ docs: tari-monero atomic swap Nov 26, 2021

SWvheerden mentioned this pull request Nov 29, 2021

docs: tari-monero atomic swap additional method #3627

Closed

philipr-za reviewed Dec 1, 2021

View reviewed changes

RFC/src/RFC-0241_AtomicSwapXMR.md Outdated Show resolved Hide resolved

hansieodendaal reviewed Dec 2, 2021

View reviewed changes

hansieodendaal reviewed Dec 4, 2021

View reviewed changes

SWvheerden force-pushed the sw_xtr-xmr_rfc branch 3 times, most recently from f984b79 to fde52df Compare December 6, 2021 14:57

hansieodendaal previously approved these changes Dec 6, 2021

View reviewed changes

stringhandler reviewed Dec 7, 2021

View reviewed changes

RFC/src/RFC-0241_AtomicSwapXMR.md Outdated Show resolved Hide resolved

stringhandler reviewed Dec 7, 2021

View reviewed changes

RFC/src/RFC-0241_AtomicSwapXMR.md Outdated Show resolved Hide resolved

stringhandler reviewed Dec 7, 2021

View reviewed changes

SWvheerden dismissed hansieodendaal’s stale review via 3748dfd December 7, 2021 12:12

hansieodendaal reviewed Dec 8, 2021

View reviewed changes

stringhandler changed the title ~~docs: tari-monero atomic swap~~ docs: RFC-0241 tari-monero atomic swap Dec 8, 2021

philipr-za reviewed Dec 9, 2021

View reviewed changes

sdbondi reviewed Dec 9, 2021

View reviewed changes

CjS77 reviewed Dec 9, 2021

View reviewed changes

hansieodendaal reviewed Dec 14, 2021

View reviewed changes

hansieodendaal previously approved these changes Dec 14, 2021

View reviewed changes

stringhandler changed the title ~~docs: RFC-0241 tari-monero atomic swap~~ docs: rfc-0241 tari-monero atomic swap Jan 1, 2022

stringhandler previously requested changes Jan 1, 2022

View reviewed changes

SWvheerden dismissed hansieodendaal’s stale review via 0708e61 January 10, 2022 06:40

SWvheerden force-pushed the sw_xtr-xmr_rfc branch from 1a161d3 to 0708e61 Compare January 10, 2022 06:40

SWvheerden force-pushed the sw_xtr-xmr_rfc branch from 0708e61 to cf6bca5 Compare January 10, 2022 06:52

SWvheerden and others added 2 commits January 11, 2022 10:30

Add XMR XTR swap RFC

dd83284

Co-authored-by: Stan Bondi <sdbondi@users.noreply.github.com> Co-authored-by: Philip Robinson <simian@tari.com>

Add link to how comments can be made

1edc119

SWvheerden force-pushed the sw_xtr-xmr_rfc branch from 7d61177 to 1edc119 Compare January 11, 2022 08:31

Merge branch 'development' into sw_xtr-xmr_rfc

aa2fceb

philipr-za approved these changes Jan 13, 2022

View reviewed changes

philipr-za added the mq-approved label Jan 13, 2022

Merge branch 'development' into sw_xtr-xmr_rfc

fdba214

Merge branch 'development' into sw_xtr-xmr_rfc

3bd44e2

aviator-app bot merged commit 58aa914 into tari-project:development Jan 14, 2022

SWvheerden deleted the sw_xtr-xmr_rfc branch January 17, 2022 07:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs: rfc-0241 tari-monero atomic swap #3623

docs: rfc-0241 tari-monero atomic swap #3623

SWvheerden commented Nov 26, 2021

philipr-za left a comment

hansieodendaal left a comment •

edited

Loading

hansieodendaal left a comment

hansieodendaal left a comment

stringhandler Dec 7, 2021

hansieodendaal Dec 7, 2021

SWvheerden Dec 7, 2021

stringhandler Dec 7, 2021

hansieodendaal left a comment

hansieodendaal Dec 8, 2021

hansieodendaal Dec 8, 2021

hansieodendaal Dec 8, 2021

philipr-za left a comment

sdbondi left a comment

sdbondi Dec 9, 2021

SWvheerden Dec 9, 2021

CjS77 Dec 9, 2021

sdbondi Dec 9, 2021

sdbondi Dec 9, 2021

sdbondi Dec 9, 2021 •

edited

Loading

sdbondi Dec 9, 2021 •

edited

Loading

CjS77 left a comment

CjS77 Dec 9, 2021

CjS77 Dec 9, 2021

hansieodendaal left a comment

hansieodendaal left a comment

stringhandler left a comment

SWvheerden commented Jan 10, 2022

philipr-za left a comment

	Pop the top element, converts it to a Ristretto point, and pushes this to the stack.
	Posp the top element, which must be a valid Ristretto scalar, calculates the corresponding Ristretto point and pushes this to the stack.

		Doing atomic swaps with Monero is more complicated and requires a cryptographic dance to complete as Monero does not
		implement any form of HTLC's or the like. This means that when doing an atomic swap with Monero, most of the logic will

	either party to claim the script with the lapse transaction. The counterparty can then claim the Monero. However, this
	either party to claim the Tari funds with the lapse transaction. The counterparty can then claim the Monero. However, this

	private key part as input data to the script, evaluated via the operation Ed25519Point. This TariScript operation will
	private key part as input data to the script, evaluated using the `ToEd25519Point` operation. This TariScript operation will

docs: rfc-0241 tari-monero atomic swap #3623

docs: rfc-0241 tari-monero atomic swap #3623

Conversation

SWvheerden commented Nov 26, 2021

Description

Motivation and Context

philipr-za left a comment

Choose a reason for hiding this comment

hansieodendaal left a comment • edited Loading

Choose a reason for hiding this comment

hansieodendaal left a comment

Choose a reason for hiding this comment

hansieodendaal left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hansieodendaal left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philipr-za left a comment

Choose a reason for hiding this comment

sdbondi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sdbondi Dec 9, 2021 • edited Loading

Choose a reason for hiding this comment

sdbondi Dec 9, 2021 • edited Loading

Choose a reason for hiding this comment

CjS77 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hansieodendaal left a comment

Choose a reason for hiding this comment

hansieodendaal left a comment

Choose a reason for hiding this comment

stringhandler left a comment

Choose a reason for hiding this comment

SWvheerden commented Jan 10, 2022

philipr-za left a comment

Choose a reason for hiding this comment

hansieodendaal left a comment •

edited

Loading

sdbondi Dec 9, 2021 •

edited

Loading

sdbondi Dec 9, 2021 •

edited

Loading