Serai DEX integration

Research
1

I summed up some questions from the Serai developer here:

and here:

5 Likes
2

:wave:

I’m here as a combination of wanting to put a foot forward with Grin, and also due to being nerd sniped into spending more time than I can reasonably justify on this.

On a practical note, if a reasonable Grin integration exists, I am not personally against integrating it. As with any effort to make something, someone needs to decide it’s sufficiently worth doing. I won’t “ask Grin” for someone to put in the effort, for a variety of reasons (unstable API while we’re pre-launch, lack of documentation, it assumes the Grin community has resources to spare, it assumes someone in Grin is so interested…), but I almost certainly will not personally be able to spend the time needed to handle such an effort in its entirety.

I did prepare a document on how an integration may be viable however.

It covers my understanding of the actual cryptography behind producing Grin transactions, lifted from Contracts - Grin Documentation (with alternate notation), the traditional Serai flow (though that probably is still missing information for anyone who truly wants to get into it), and then starts on reconciliation.

Please note I conflate private keys with commitment masks.

I believe using:

  • Private key transfers of outputs in order to receive GRIN with just a single interaction
  • A half GB lookup table to recover amounts from on-chain outputs
  • Users publishing their nonces to receive (not to send), then Serai publishing their signature share

An amenable system could be built. Serai can parallelize expected outputs to achieve execution in logarithmic time. Unfortunately, I believe the multisig may be able to steal upon recipience and upon sending without identifiability. If we had identifiability, we could slash the multisig to ensure users are made whole, but adding identifiability increases interactivity/computational complexity.

If someone experienced with Grin on a theoretical level could review my work for sanity, it’d be appreciated. If anyone can propose alternate schemes which improve interactivity/performance or restore identifiability, those would also be appreciated. A couple proposed schemes when sending out do offer identifiability, just with their own interactivity/performance issues. I imagine a similar scheme can be quickly proposed for recipience, yet again with barely there viability (if any).

I’m happy to clarify any questions about the Serai side of things (which will be the primary determinant for practicality).

8 Likes
3

I’ve made further edits to the document to the point I do believe there’s a protocol which is sufficiently practical. The only true edge case I still see is how we’d be unable to perform refunds in the native GRIN on any error.

This shouldn’t practically be an issue, they can simply burn the sriGRIN when they’re online to trigger the general out protocol, but if the network’s capacity is at its limit, we can’t mint sriGRIN. That mean we’d be unable to refund in such cases.

The reason for being unable to simply refund in GRIN on error is:

  1. The user is presumed offline, having walked away
  2. We can’t distinguish them never sending their slatepack from them being censored

The general out protocol solves this by “If we don’t receive the slatepack on time, refund to sriGRIN”. This gives the user another chance to send out, and if they actually are being censored, they can defer to social consensus.

If we remove the “refund to sriGRIN” part, which is what’d happen if we’re explicitly refunding via GRIN, then we simply have an expected slatepack with no guarantee it’ll appear in a timely fashion with no way to distinguish if the multisig is malicious.

It’d definitely be a notable amount of effort to integrate. It needs cryptographic review, a robust threshold signing protocol, a suitable spam proof, and a new data pipeline. It seems possible + feasible, if the effort was put in though.

2 Likes
4

@kayabaNerve tell us your thought if grin or any MW coin like beam becomes non interactive will it help on the integration in dex or cex

5

Non-interactivity would greatly help here, and I assume it’d frequently help with integrations into other projects.

1 Like
6

Thank you for this work! @Cobragrin we need someone to comment on this and provide perspective

2 Likes
7

If I could request an area of focus, it’d be on wallet scanning in a MPC scheme and the idea of multiplicative factors (n ** 2**64 to offer sufficient spacing) to enable using keys with known relations.

Even if the MPC Bulletproof can be proved with an amount embedded, I’m unsure what the exact guarantees of such a scheme would be (we’d need to guarantee the only valid Bulletptoofs created are ones with amounts embedded, and they can’t be cheated nor malleated otherwise).

Thanks to anyone who spends the time.

4 Likes
8

A solution can be offline transaction relaying, maybe similar to grinbox. I dont have the sufficient knowledge about this much.
Or this bounty can be revived, can be considered for non interactivity.
I am on the interactive and minimal, secure side tough…

1 Like
9

Not to be rude, yet not only does that reply not provide any feedback on the work I performed, it also doesn’t acknowledge the issues presented.

Let’s assume a Grinbox instance exists, and a user wants to send coins to Serai.

  1. Does Serai have to perform a DKG, a O(n^2) operation with reduced fault tolerance if robust, or can it reuse keys? I described a potential way for multiplicative factors to enable key reuse, yet I don’t have the experience to state it as valid.

  2. Serai would have to be able to recover the amounts from the blockchain alone in order to enable third-party verifiability. Can MPC Bulletproofs embed an amount, or is Tari’s documentation correct in saying they can’t? If they can’t, can you posit a more efficient scheme than my suggestion of a notably sized lookup table?

These are just two design considerations, and active questions, detailed in the document I posted. As you can see, neither are impacted in the slightest if we run a Grinbox server or if we don’t.

While we do have complexities related to interactivity, the primary design issues remaining are about the underlying cryptography which causes the interactivity requirement. Not the interactivity itself. That only has an issue in how we can’t guarantee termination of a process given an honest multisig which isn’t being censored (which creates edge cases, such as the inability to guarantee a refund in GRIN).

While I thank you for taking even just a moment to chime in, I’d ask that if you were to again help, you’d first read through the background I established. I would really appreciate the assistance however, as for anyone to consider making this reality (whether myself or a community member), the theory must be straight. At this time, it isn’t.

Let me know if I can clarify any of my questions, or the problem space itself. The best note may be how Serai is a decentralized exchange, yet it isn’t a P2P exchange like Bisq.

Thanks again, and hoping for another response :slight_smile:

5 Likes
10

Well, sorry for misunderstanding. :palms_up_together: I dont have the knowledge enough to give you a perspective. I just focused that offline problem and remembered the solution ideas.

Better it will be core developers can give idea to you. @tromp @Yeastplume @oryhp @vegycslol.

I really appreciate your good will and effort @kayabaNerve .Thank you really.

5 Likes
11

Totally understand. I appreciate you chiming in on that angle, trying to help specifically there as you can. We do have our own solution for data availability + consensus already though :slight_smile:

4 Likes