Blackwolfsa left before I could comment that the inaccuracies I saw relate to the DLEq proof (I have no idea what they're defining) and expected usage of it. Their "two method design", where one avoids it, isn't optimal if they actually want interoperability. Just leave it off chain. Not to mention h4sh3_d's above commentary, which I haven't reviewed. Hoping this message gets to them regardless.

Hi, kayabaNerve_, sorry my IRC client disconnected. Saw the reply on the monero logs.

For the DLEQ proof, Tari runs on Ristretto with a second generator point for the Pedersen commitments. So when you have a private key x, and you have the public keys x.G on Ristetto and x.G on Ed25519. To avoid confusion we just call the Ed25519 generator point M in the RFC.

With regards to the script, its hard limits on when spending is allowed. So theoretically it is possible for the transaction to be stuck in the mempool if the network is busy enough, the fee is too low and the lock heights are not sufficiently long enough. This will allow the leakage of both parts of the Monero key if it was the "swap" transaction

and now you want to claim the refund. The lapse transaction would leak the same key again thou. But in the same time it is also possible to bump the fee of an already signed transaction by creating a new transaction with high fees and combining the two transactions.

But if you missed your block height window, the script will block you.

Blackwolfsa: Ristretto points are all Ed25519 points in the prime subgroup, there is no difference except in encoding/decoding.

yeah, but as far as I have it, Ed25519, as used by Monero, might not be Ristretto points as they use different subgroup. Right?

No it is the same, canonical Ristretto points are always in the prime subgroup (non-canonical points can be out of the subgroup, but if you compress and decompress you always land in the prime subgroup).

At least, according to isis. You could probably write a little heuristic test to check that.

The actual curve stuff I am not that clued up. But I did write a test using Dalek and looked at the actual code. The edwards points used is not the same between Ed25519 and Ristretto.

Can you share your test code?

Sorry I deleted it. Was a unit test I created using Dalek to create two public keys, one on Ristretto and on Ed25519 as used by Monero-RS, and compared their Edwards points.

Create public keys how?

If you compare the compressed representation, they won't be the same. You'd have to compare one of the decompressed representations (like `ge_p3`, etc.).

Yeah, I tried to look at the actual edwards points

In about 24 hours there will be a meeting in this channel: monero-project/meta #637

Blackwolfsa: That covered none of my DLEq concerns. The as described off chain proof doesn't appear to match MRL at all, but that could just be due to its failure to render. The on chain proof is incredibly brittle, adds node complexity, isn't needed...

Also, Ristretto points decode to prime subgroup Ed25519 points. Ristretto points encoded != Ed25519 points encoded. Any debugging you did probably displayed the encoded forms, hence the distinction.

github.com/dalek-cryptography/curve…lek/blob/main/src/ristretto.rs#L968 calls the EdwardsPoint code which supplies the Ed25519 basepoint internally. Ristretto's basepoint is equivalent despite the distinct binary representation when encoded.

I also code link my own impl which may be more succinct yet it's embedded into another project I don't care to share here.

As a side note, I really hate how Dalek tells you it's correct and you're wrong. I've had two instances where I'd need to modify dalek for my work. One being the fact you can't Ed -> Rist, despite it being a wrapper struct (though this one is justifiable as which square root to use isn't defined so dalek would be opinionated for doing so and not compatible with other impls who also follow the protocol) AND lack of FieldElement

access. You can't implement the XMR hash to curve using dalek because dalek doesn't let you implement any hash to curve. Since it's the only ed25519 lib in Rust worth anything, and its quality prevents others from serious attempts at one, it's legitimately not feasible to do a Rust hTC right now without C bindings, defeating the purpose.

mmm, well that makes things a tad bit easier if we don't need a DLEQ proof.

but on the on-chain DLEQ. We don't have one on-chain, except for the PTLC type script. The actual method that uses DLEQ, that's off-chain and only between the two parties.