[DRAFT] Succinct Atomic Swaps

[GeneFerneau]

Link to the rendered text

[tromp]

Please provide a "Link to rendered text" in top description like I have in my Safe cancel PR.

Also, note that proposals should be called text/0000-<name>.md, not text/002x-<name>.md

[tromp]

There seems to be a ton of details missing here. Where is the description of how to build and verify all 5 transactions shown in the diagram?

[GeneFerneau]

There seems to be a ton of details missing here. Where is the description of how to build and verify all 5 transactions shown in the diagram?

There are only three transactions in the swap proper (plus the two funding transactions). I was only describing the transactions actually involved in the funded swap, but can add a sentence describing the need to fund the swap. I took the diagram you provided to be showing the state transitions, not independent transactions.

I can also add a few lines about how transactions are built. Basically, the transactions (refund and main) on the Grin side are built like normal 1-in-2-out transactions. The refund is a self-spend co-signed by the other party (they have no inputs/outputs from the other party). The main transaction is essentially just a 1-in-2-out transaction, that reveals Alice's secret.

The non-Grin transaction uses a multisignature (potentially time-locked). If a time-lock is used, the funds are returned to the funder when the timer expires.

[tromp]

My original picture showed outputs in boxes and transactions (with locktimes and possible reveal properties) as edges between them. On the Grin side, there were 5 outputs, and 5 transactions between them.
In a normal execution, the 3 refund/revoke related of these Grin transactions do not happen, and the remaining 2 Grin tx + 1 BTC tx are what make this a "3-transaction" swap.
In your new picture you seem to have put the transaction names on the boxes, which makes no sense to me.

[GeneFerneau]

In a normal execution, the 3 refund related of these Grin transactions do not happen, and the remaining 2 Grin tx + 1 BTC tx are what make this a "3-transaction" swap.

The 3 refund version of Succinct Atomic Swaps is not currently possible on Grin, because they require relative timelocks (using NRD kernels). I mention this in the RFC:

Somsen also has a variant using relative timelocks, which could be implemented on Grin using No Recent Duplicate kernels [4].
This would allow for a more automated way to post the refund transaction, but requires NRD kernel activation on mainnet.

The version of atomic swaps I implemented, and the one represented in the RFC, is closer to the version described in the Grin documentation.

If a version using 5 transactions for the main swap is considered "3-transaction" because the refund doesn't normally appear on chain, then the version I've implemented is a "2-transaction" swap.

In your new picture you seem to have put the transaction names on the boxes, which makes no sense to me.

The boxes represent the transactions locking funds (and funding transactions), the names describe their purpose. The boxes without titles show the UTXO destination, and the descriptions over the edges show how the atomic nonces are revealed. I labeled them to clarify when referring to the diagram example in rest of the section. I thought this is along the lines of what you requested, am I mistaken?

[tromp]

Like you said, you cannot implement the 2-tx swap without relative timelocks.

What you implement is the 3-tx swap, where the 2 Grin txs of a successful execution are Alice's funding tx, and what Somsen calls the Success transaction.

What Somsen calls the Revoke transaction, Refund transaction #1, and Timeout transaction are needed for handling abnormal executions. The relative timelocks are only needed in the 2-tx version (that doesn't perform the "Success transaction"), and can otherwise be replaced by absolute timelocks as I did in my diagram.

Your new ASCII diagram shows amount and blinding factors (output properties) in boxes,
and shows locktimes and revealing properties (kernel properties) on edges. Yet it names boxes as transactions. This is quite confusing.

[GeneFerneau]

What Somsen calls the Revoke transaction, Refund transaction #1, and Timeout transaction are needed for handling abnormal executions.

Right, and I did not include the Revoke transaction, because it only makes sense as a setup for the two relative timelocked transactions (Refund #2 and Timeout). If you switch the transactions to use absolute timelocks, they effectively serve the same purpose of the Refund #1 transaction, so why bloat/complicate the impl? You gain no advantage, since the Revoke transaction flow is meant to be an automated way to abort the swap, or award Bob the coins if Alice is unresponsive/inactive.

The relative timelocks are only needed in the 2-tx version

No, if you look at the diagram, relative timelocks are needed for both the Refund #2 and Timeout transactions.

What you implement is the 3-tx swap, where the 2 Grin txs of a successful execution are Alice's funding tx, and what Somsen calls the Success transaction.

Again, no. I implemented what Somsen calls the Success and Refund transactions, and leave the Revoke (and its children) for future work when NRD kernels (i.e. relative timelocks) become available.

Your new ASCII diagram shows amount and blinding factors (output properties) in boxes,
and shows locktimes and revealing properties (kernel properties) on edges. Yet it names boxes as transactions. This is quite confusing.

I don't understand what's confusing about the new diagram. To me it's a more straightforward representation of the version of atomic swaps that I've implemented. I'd be interested to get feedback from more people.

The new diagram is also closer to Somsen's diagram where the boxes with the inputs and outputs are labeled with the transaction titles. Is it confusing to you because you originally thought of the edges as transactions?

[tromp]

and leave the Revoke (and its children) for future work

I'm afraid your understanding of SAS is not quite correct. The Revoke tx is essential to its correct operation. The relative timelocks in the followups are not, and can safely be replaced by absolute timelocks if you always use the 3-tx version of SAS.

[GeneFerneau]

I'm afraid your understanding of SAS is not quite correct.

It's not that my understanding is incorrect, I am trying to implement SAS with what's currently available on Grin.

I tried to follow the SAS protocol as closely as possible, deferring to the implementation described in the official Grin documentation for atomic swaps when something didn't seem possible.

Admittedly, my implementation is much closer to the Grin documentation atomic swaps than to SAS.

The relative timelocks in the followups are not, and can safely be replaced by absolute timelocks if you always use the 3-tx version of SAS.

After re-reading the SAS specification, I saw question in the FAQ about using absolute timelocks:

-  Is it possible to implement this protocol on chains which only support absolute timelocks?

   Yes, but then Bob must spend his swapped coins before the timelock expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST confirm before the timeout_tx becomes valid, which may become a problem if fees suddenly rise. The refund_tx can also not be allowed to CPFP the timeout_tx, as they must confirm independently in order to invalidate the success_tx first.

I rewrote the RFC to more closely follow SAS, but have some questions about the feasibility on Grin.

• How to do the multisignature signing on Grin Revoke?
  • Like normal with Alice having full control over the UTXO(s) being spent?
  • Does it require Grin multisignatures to be implemented first?
• The Grin Timeout transaction sends Grin to Bob, without revealing Bob's atomic nonce to Alice. Alice cannot retrieve the funds locked on the other chain, if that happens.
  • Is this intentional, or an oversight in the protocol?
  • If intentional, should Bob have to reveal his atomic nonce to claim the Grin Timeout transaction?
  • If Bob doesn't reveal his nonce, this could be a Denial-of-Service attack vector on Alice
• It is unclear who the signer of sigTimeoutAlice and sigTimeoutBob are
  • Does Alice sign sigTimeoutBob and Bob sign sigTimeoutAlice (because sigRefundBob is signed by Alice)
  • If Alice signs sigTimeoutBob, she doesn't pre-sign the Grin Timeout transaction, so how does that work?

[phyro]

I think it's important to check which inputs/outputs the other party contributes when creating a transaction with multisig outputs. For instance, when Alice and Bob are creating the "Grin Refund" transaction, if Bob adds an additional output 0*H + r_bob*G to the slatepack the transaction captures this output, he could, after the "Grin Revoke" transaction, create an output 0*H + r_bob*G on the chain to block the "Grin Refund" transaction (duplicate outputs can't exist). This way, he can take money from the "Grin Timeout" transaction and then possibly negotiate with Alice to split the value that is locked in the Bitcoin side under a multisig. Similarly, Bob could silently add an input to the "Grin Refund" tx and later spent that input to make the refund tx invalid.
I think the code in mimblewimble/grin-wallet#618 needs to check exactly what inputs/outputs were created in these transactions to prevent any such blocking that is possible on a MW chain. I'm not sure whether the code already checks for such cases, but I'm dropping a comment anyway since it's something we don't want to miss.

P.S. Regarding the diagrams, right now a diagram where txs are edges and outputs vertices make a bit more sense to me although I'll admit that I'm fairly new to any of the two representations as I've never thought about representing txs/outputs with diagrams before.

[GeneFerneau]

I think it's important to check which inputs/outputs the other party contributes when creating a transaction with multisig outputs.

I agree, it's definitely important. Didn't consider it at first, but Bob or Alice could attempt attack each other if the outputs aren't specified, and multisigned.

Currently, in Grin only the kernels are multisigned using the blinding factors and offsets of both signers. Output multisignatures still need to be implemented. I can start working on output multisignatures, to get an idea for how much work that's going to take.

Hopefully, it should be pretty straightforward, since an aggregate key (r_alice*G + r_bob*G) can be used to lock and create a rangeproof over the output.

I think the code in mimblewimble/grin-wallet#618 needs to check exactly what inputs/outputs were created in these transactions to prevent any such blocking that is possible on a MW chain.

Absolutely, it does need to verify inputs/outputs, and the code currently doesn't do that. It's a relatively small change, so I'll start working on that today.