MCIP Draft - View Authenticated Sender Memo #58
Conversation
briancorbin
changed the title
briancorbin
changed the title
briancorbin
changed the title
| # Rationale and alternatives | ||
| [rationale-and-alternatives]: #rationale-and-alternatives | ||
|
|
||
| An alternative would be to generate the SenderMemoCredential during signing and modify the TxOut during the signing process. This would require more discovery as it is uncertain if this is possible without regenerating all of the contents of the TxOut and TxPrefix, which may not be desireable (especially if signing using a hardware wallet). |
There was a problem hiding this comment.
We currently have designed the hardware wallets stuff to have one round where it computes memo hmacs for these sender memos (using the spend private key), and then a second round where it actually signs ring mlsags.
There was a problem hiding this comment.
If copper really wants us to provide just one payload, and they would have a round where they do memo signing and then another round where they do transaction signing, and those two rounds happen in their application, that seems like it should be possible, it will just make the UnsignedTx object a lot messier.
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| With the introduction of the ViewAccountKey and UnsignedTransactions, generating a SenderMemo for RTH became impossible because of the requirement of the Subaddress Spend Private Key during the creation of the TxOuts for the transaction. |
There was a problem hiding this comment.
I don't think it's actually impossible now, we have a plan here: mobilecoinfoundation/mobilecoin#2585
The idea is to refactor the MemoBuilder object implementation that currently requires the spend key to make it more abstract, and allow that to be a hardware device connection instead.
The only one who is impacted here is Copper's multiparty compute flow.
|
|
||
| An alternative would be to generate the SenderMemoCredential during signing and modify the TxOut during the signing process. This would require more discovery as it is uncertain if this is possible without regenerating all of the contents of the TxOut and TxPrefix, which may not be desireable (especially if signing using a hardware wallet). | ||
|
|
||
| The rationale for adding the ViewAuthenticateSenderMemo is that it allows users to utilize RTH with an offline transaction signer or hardware wallet. |
There was a problem hiding this comment.
The other main alternative is, do nothing. Then, RTH cannot be used with Copper (at least, the authenticated sender memos cannot be).
This may be acceptable -- after all, we did not prioritize making RTH work with mobilecoind, and I'm not sure it works with full-service right now? You would have to tell me.
| # Unresolved questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| > - Is it possible to modify just the encrypted memo portion of a TxOut without requiring the TxPrefix and OutputSecrets to be regenerated? |
There was a problem hiding this comment.
The TxPrefix would change, but the output secrets would not.
There was a problem hiding this comment.
Okay, then that might actually be a plausible solution for offline transaction signing
|
So the main thing that makes me think twice about this is, as you say, it reduces the security from the recipient's point of view -- when validating these memos, the signer could be someone who stole the view key (rather than needing to be someone who has the spend key). If I'm a client and I receive a TxOut with a view authenticated sender memo, do I validate it and then display it in basically the same way as the existing sender memo? So then as a client, I trust view and spend-based sender memos equally? I wonder if there's a way to make it so that clients only trust view authenticated sender memos when it's necessary. So for instance, for a copper-style multisig account, maybe the public address has a flag that says to accept view authenticated sender memos? And then if I'm a client, I only respect view authenticated sender memos if the public address contains that flag? And other "normal" account types aren't affected, and the client needs to see a spend-key authenticated sender memo in order to treat the origin of the payment as verified. This would prevent any regression around what happens if I'm a "normal" user and someone steals my view key, which today is bad, but doesn't enable forging these authenticated memos. That's my 2 cents for now, will think some more |
Rendered Proposal