What is the most critical problem of Grin?

It should not be a problem In this case the ephemeral adres is just a slatepack address that does not use a master public key, but a derived pubic key for an account or single address.
The SlatepackAddress is a shareable bech32 encoded ed25519 public key that can be used both to *route synchronous transactions* and to *encrypt asynchronous transactions*

The longer I work with Grin, the less I think the three steps is an issue. Just more code around it might be handy, e.g. automatically picking up slatapacks from emails and messaging APPs such as signal.
One other minor problem with 2 step is that a recipient can fake not receiving it, wait for a second transaction and then accept both.But this is also possible with RSR flow.
In both cases the user should cancel the first transaction before sending again.

1 Like