-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TxSummary digest #52
TxSummary digest #52
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable to me, thank you for the detailed write up.
Do you think it would make sense to add a "worst possible case" calculation of how much memory the hardware wallet will need to support, based on a transaction that has the max inputs/outputs?
Koe made a different estimate of the sizes of Tx's due to membership proofs which is larger than mine, in MCIP #21
I have not actually done this calculation myself. We could also write a unit test or something that measures this maximum size. You're right, we should probably document what the actual worst possible case is at the current version (v2) |
I think it's also valuable (if not more valuable) to document how much it would be following this change. This will make it easier for potential hardware integrations to have a quick go/no-go based on memory requirements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Incorporate several of @remoun's and @nick-mobilecoin's suggestions. Co-authored-by: Remoun Metyas <[email protected]> Co-authored-by: Nick Santana <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
text/0052-tx-summary-digest.md
Outdated
The verifier similarly computes this | ||
`extended-message-and-tx-summary digest` and verifies that the MLSAGs sign this. | ||
|
||
When a hardware wallet is asked to sign an MLSAG, we can give it now the `extended_message_digest` | ||
and the `TxSummary`, and it can compute the appropriate digest from this for the MLSAG to sign. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means we'll need a merlin implementation that runs on embedded devices, correct?
As a side note, I don't think we'll ever need to worry about running into a big-endian embedded device, but there's currently an endianness bug in our limited STROBE implementation used in merlin, which we'd want to fix before porting to C.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the rust merlin implementation not work? can we just fix that one?
Co-authored-by: isis lovecruft <[email protected]>
Co-authored-by: isis lovecruft <[email protected]>
Co-authored-by: isis lovecruft <[email protected]>
Co-authored-by: Nick Santana <[email protected]>
Co-authored-by: isis lovecruft <[email protected]>
Co-authored-by: isis lovecruft <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really well written. Thank you!
Co-authored-by: Eran Rundstein <[email protected]>
Co-authored-by: Eran Rundstein <[email protected]>
Co-authored-by: Eran Rundstein <[email protected]>
Co-authored-by: Eran Rundstein <[email protected]>
Going to hold this one an extra day due to comments |
A proposal to introduce a
TxSummary
object and incorporate it into the digest which MLSAG's sign, to help hardware wallets.Rendered Proposal