Skip to content

Conversation

@cbeck88
Copy link
Contributor

@cbeck88 cbeck88 commented Oct 10, 2022

A proposal to introduce a TxSummary object and incorporate it into the digest which MLSAG's sign, to help hardware wallets.

Rendered Proposal

Copy link
Contributor

@eranrund eranrund left a 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?

@cbeck88
Copy link
Contributor Author

cbeck88 commented Oct 11, 2022

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

Currently (protocol v0), Merkle membership proofs constitute the bulk of transaction size. A 1-input/1-output transaction is ~21 kB, with membership proofs taking up ~17 kB (assuming membership proofs with 32 elements, representing a Merkle tree 31 layers deep). In a 16-input/16-output transaction (the maximum size of a transaction), membership proofs occupy ~275 kB out of ~325 kB.

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)

@eranrund
Copy link
Contributor

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

Currently (protocol v0), Merkle membership proofs constitute the bulk of transaction size. A 1-input/1-output transaction is ~21 kB, with membership proofs taking up ~17 kB (assuming membership proofs with 32 elements, representing a Merkle tree 31 layers deep). In a 16-input/16-output transaction (the maximum size of a transaction), membership proofs occupy ~275 kB out of ~325 kB.

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.

Copy link
Contributor

@remoun remoun left a 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 <remoun.metyas@gmail.com>
Co-authored-by: Nick Santana <nick@mobilecoin.com>
Copy link
Contributor

@isis-mc isis-mc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines 66 to 70
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.
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Chris Beck and others added 2 commits October 18, 2022 11:04
Co-authored-by: isis lovecruft <79881025+isis-mc@users.noreply.github.com>
Chris Beck and others added 13 commits October 18, 2022 12:11
Co-authored-by: isis lovecruft <79881025+isis-mc@users.noreply.github.com>
Co-authored-by: isis lovecruft <79881025+isis-mc@users.noreply.github.com>
Co-authored-by: Nick Santana <nick@mobilecoin.com>
Co-authored-by: isis lovecruft <79881025+isis-mc@users.noreply.github.com>
Co-authored-by: isis lovecruft <79881025+isis-mc@users.noreply.github.com>
@cbeck88 cbeck88 added the final-comment-period This RFC is in the final-comment period for the next 24h label Oct 21, 2022
Copy link
Contributor

@eranrund eranrund left a 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!

cbeck88 and others added 6 commits November 3, 2022 10:18
Co-authored-by: Eran Rundstein <eran@rundste.in>
Co-authored-by: Eran Rundstein <eran@rundste.in>
Co-authored-by: Eran Rundstein <eran@rundste.in>
Co-authored-by: Eran Rundstein <eran@rundste.in>
@cbeck88
Copy link
Contributor Author

cbeck88 commented Nov 3, 2022

Going to hold this one an extra day due to comments

@cbeck88 cbeck88 merged commit 788c995 into mobilecoinfoundation:main Nov 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

final-comment-period This RFC is in the final-comment period for the next 24h

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants