Grin-Bitcoin Adaptor Signature Atomic Swap update thread

OK, I understand now what you mean, thanks for clarifying. Aside from the mempool fee issues we discussed, I don’t think there’s much that can be done. Perhaps communicating over Tor will make targeted attacks less likely? This problem seems inherent to any protocol that requires a participant to interact with the p2p network within a certain period of time.

“Seen first” is a propagation rule, not a consensus rule. It’s generally unsafe to make security assumptions based on propagation rules. If Alice talks to miners directly, and offers them a fee to mine her tx instead of Bob’s, then she gains the upper hand. Her nonce/secret won’t be revealed to Bob until her Grin tx is confirmed, and if she’s lucky enough to get a confirmation on the BTC tx before her Grin tx confirms, she will in fact walk away with all the coins.

I’m not sure if the non-interactive aggregation properties of Grin may make out-of-band transaction replacement harder (I suspect Alice can help miners to undo the aggregation of Bob’s tx, seeing as she knows the tx?), but ultimately this still doesn’t guarantee the attack won’t occur.

1 Like

That’s not necessarily the case. As soon as Alice’s tx is in a node’s mempool controlled by Bob, he has access to the final signature, and can retrieve Alice’s secret. Same in reverse for txes with Bob’s secret.

I fully agree about not relying on propagation rules for security, and it’s partially why I’m having trouble seeing the advantages of the Revoke flow, over just using the Success and Refund #1 txes (at least, when using absolute timelocks).

The Revoke flow makes a lot of sense when you have relative timelocks, because the order of accepted txes can be enforced by consensus. But I don’t see the advantage with absolute timelocks, since just using Success and Refund #1 seems to be sufficient (and simpler) to achieve a secure swap.

Is there an added benefit to using the Revoke flow with absolute timelocks?

1 Like

Update 2021/06/04-11

Over the last week, I have been working on changes for V5 slates. I moved the changes for atomic swap slate types into V5, along with multisig stuff. Also, added mutlisig transaction flow enum types, and slate types.

The next steps are to build multiparty outputs (multisig). Similar to atomic swap transactions, multisig transactions will require four communication rounds. This fits nicely, and should work well with the atomic swap transactions that require creating a multiparty output (Revoke).

The implementation should be pretty straightforward, so I hope to finish by early-to-mid next week. After multiparty outputs are done, just need to modify atomic swap Success and Refund #1 transactions to select and verify the multiparty output created by the Fund transaction.

To complete the SAS implementation, the Revoke, Refund #2, and Timeout transactions also need to be implemented.

I’ll also be updating the RFC with more details about slate changes, and how each transaction is built (e.g. one slate per transaction vs. one slate for the Revoke + Refund #2 + Timeout txes).

Thanks for reading

8 Likes

Note that I specifically said “if Alice talks to miners directly”, meaning Alice circumvents the p2p network (and thus everyone’s mempool) and asks miners to mine her transaction directly. Perhaps my post will make more sense now, with that clarification in mind.

Well, I’ve been arguing that this isn’t secure. I’m not sure what more I can say to make the need for Revoke more clear. You need to wait for Revoke to confirm, and only then should you send Refund (regardless of whether you use abs. or rel. timelocks), otherwise it can cause race conditions where both secrets can get revealed. The example in my previous post (which is hopefully more clear now) even shows how you can gain a clear advantage in the race and potentially steal all coins by bypassing the mempool and talking to miners directly.

5 Likes

Beyond that, Refund #1 cannot be a single Grin tx since it has two separate spending conditions.

2 Likes

Yes, you bring up a good point. Refund #1 from the original diagram is actually purely there to allow for more efficient recovery, reducing the failure recovery case from 2 transactions to 1 in the case where your counterparty becomes unresponsive before Success is ever signed. In all cases it is entirely safe to simply drop Refund #1 from the spec (since Refund #2 always works), and this clearly seems appropriate for the specific case of Grin. Note that it’s also safe to broadcast Revoke and Refund #2 together IF Success was never signed, since then there’s no risk of race conditions.

4 Likes

So, is the atomic swap described in grin docs also insecure? If so, why?

1 Like

That one looks secure to me, but is much less attractive in that it requires two bitcoin transactions, and requires the bitcoin holder to start. Also, the hashlock reveals the nature of the transaction.

1 Like

For the hashlock, I would replace with a normal transaction signature under the aggregate secrets used in the atomic swap, so it would look like a normal transaction.

Could also wrap the Bitcoin transaction in a timelock, but not strictly needed. The Bitcoin tx timelock could even have an adaptor signature to reveal Bob’s secret for Alice to retrieve the locked Grin (either ECDSA or Schnorr adaptor signature, when taproot activates later this year).

Why would there need to be two Bitcoin transactions?

Why would the Bitcoin user have to start?

With using a signature under the aggregate swap secrets, the Grin side would need to go first (or Alice and Bob would need to exchange swap public keys out-of-band).

On a closer reading, it is not a hashlock, but a regular secret public key x*G. It is still abnormal in having a alternate timelocked spending condition.

I don’t know what you mean by wrapping here.

Because that’s how atomic swaps worked before S.A.S. Bob locks up bitcoin that either gets refunded or spent by Alice learning a secret.
S.A.S.manages to avoid the refund by first setting up a more complicated revoke mechanism on the other side.

That’s how that particular protocol is setup. You could make a variant where the Grin user starts though.

1 Like

Adding a timelock spending condition to the Bitcoin transaction (pseudo-script):

IF SIGNATURE(aliceSecret + bobSecret)
    SPEND_TO_ALICE
ELSE IF BLOCK_HEIGHT > SOME_HEIGHT AND SIGNATURE(bobPrivateKey)
    SPEND_TO_BOB

Couldn’t that be avoided with a single transaction similar to what is described above? Then there would just be the one funding Bitcoin transaction, and one locked transaction (which is the same situation as S.A.S.). With taproot, the alternate spending conditions could be hidden, only revealing the actual spend path used. So, it would look like any other taproot spend.

Update 2021/06/11-18

Over the last week, I have been working on multisig transaction building in grin-wallet. Also, made some minor tweaks to output building in grin.

Still working on the final pieces of multisig transaction building. All the backend API implementations are basically finished, and I’m going to work on adding the frontend APIs, RPCs, and wallet commands next.

Will also be adding an end-to-end test based on cmd_line_basic, to ensure everything works properly.

After all the pieces are in place for multisig transactions, I will modify the atomic swap transaction building to select and verify the multisig output. Then, it should be possible to test a variation of the atomic swaps described in the Grin documentation.

Once I have everything worked out, I’ll make updates to the RFC. There are a number of changes to slate formatting, the entire mutlisig output building, and some more details about the atomic swap that I need to add. Just want to get all the pieces in place before adding the RFC updates.

Thanks for reading

17 Likes

Update 2021/06/18-25

This week I added the remaining pieces for hooking up multisig output transactions and atomic swap transactions.

I’m currently debugging the end-to-end test, and it looks like there is a problem getting the multisig output transaction added to the PMMR. Not sure if it’s a problem with the test setup, or I’m doing something wrong in the impl.

Will keep debugging, hopefully will be able to figure it out. Will post update as soon as I solve the problem. Might be that I need to fix how the mutlisig output is spent, TBD.

I think all the pieces are in place (outside the above bug), so I’ll start writing up the necessary changes to the RFC.

Thanks for reading

14 Likes

Update 2021/06/25-07/09

Over the last two weeks, I have been fixing some broken tests. It took a while due to not being able to run doctests in a debugger (super annoying). All the tests appear to work now!

Also, spent some time cleaning up the commits in grin-wallet/#618 (main atomic swap PR). Everything should be ready for review code-wise, with maybe some straggling code cleanup issues. Functionally, everything is there.

I am still working on writing up the RFC changes for the atomic swap impl. I am not going to implement SAS, and leave that as work for someone else. I’ll be writing a separate RFC for an atomic swap scheme that more closely follows the description in Grin docs, since that is what I’ve implemented.

Thank you for all the support I’ve received from the Grin community during these past few months.

I’ll still be around, and will continue contributing to Grin. I won’t be requesting further funding for atomic swaps, but will finish the remaining work (mostly RFC stuff).

Thanks for reading

23 Likes

Thanks for all your time and effort!

4 Likes

Thank you :black_heart: looking forward to it

4 Likes

is there any new update? its been a month:(

2 Likes

I don’t think we’re waiting for Gene now. He has two rfcs ready and they need to be reviewed. Similar situation with the code.

2 Likes

what is the current development? Gene s last post is 2.5 months before. Review will be made by current repo owners or needs a soft fork etc or independent audit ?
Or another someone to implement to wallets?

1 Like
1 Like