protocol optimization: verify hash that derives view key in contract, instead of the public key, saving on *lots* of gas

[athanorlabs]

protocol optimization: verify hash that derives view key in contract, instead of the public key, saving on *lots* of gas

[TheCharlatan]

To me it seems like there is nothing enforcing that the preimage of h_a is actually corresponding to the private key of the public key P_a. The derivation of the private view key from the private spend key is just convention and not using this convention will still produce valid Monero transactions. In this case, Bob could could end up locking the Monero with another spend key s_c, without Alice noticing it. Due to the nature of Monero spend keys, she would only notice once she tries to spend the Monero.

however, if the public spend key does not correspond to the view key, then the funds cannot be viewed. before Bob locks his XMR, he can check that he can generate a view-only wallet using the summation of the two view keys.

The monero-wallet-rpc for example will happily find transactions that do not actually correspond to the spend key you have imported, as long as the view key matches.

I would like to take this opportunity to publicly invite you to continue your work as part of the Farcaster project. We definitely have a common goal, and our experiences seem to intersect nicely. Obviously I see that joining another team's half-finished project in a language that is not your first preference is by no means the most appealing thing to do, especially after having written a lot of code yourself, but I feel like this effort and especially the cryptography is best done in a group on a shared codebase. We are also keen to extend the extensive modelling and specs written by us since the publishing of the original Monero<->Bitcoin atomic swaps paper by h4sh3d to Monero<->Ethereum swaps. If you are interested in formalizing a model of your swap, contact us on #monero-swap on libera.chat.

[alxs]

Agree on this being an issue - Alice can also exploit it by providing an unrelated public key and claiming a refund, in which case Bob won't be able to reclaim his funds.

[noot]

To me it seems like there is nothing enforcing that the preimage of h_a is actually corresponding to the private key of the public key P_a. The derivation of the private view key from the private spend key is just convention and not using this convention will still produce valid Monero transactions. In this case, Bob could could end up locking the Monero with another spend key s_c, without Alice noticing it. Due to the nature of Monero spend keys, she would only notice once she tries to spend the Monero.

The monero-wallet-rpc for example will happily find transactions that do not actually correspond to the spend key you have imported, as long as the view key matches.

ah, I see what you mean, you can generate a wallet where the spend key, view key, and address don't correspond. I thought I had figured out a nice gas workaround, oh well lol. thanks for pointing this out!

I would like to take this opportunity to publicly invite you to continue your work as part of the Farcaster project. We definitely have a common goal, and our experiences seem to intersect nicely. Obviously I see that joining another team's half-finished project in a language that is not your first preference is by no means the most appealing thing to do, especially after having written a lot of code yourself, but I feel like this effort and especially the cryptography is best done in a group on a shared codebase. We are also keen to extend the extensive modelling and specs written by us since the publishing of the original Monero<->Bitcoin atomic swaps paper by h4sh3d to Monero<->Ethereum swaps. If you are interested in formalizing a model of your swap, contact us on #monero-swap on libera.chat.

I'm definitely interested in talking and seeing where we can work together when possible :) I'll reach out to you soon.