Skip to content
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

Expose the randomness used to create descriptions. #77

Closed
wants to merge 1 commit into from

Conversation

murisi
Copy link
Contributor

@murisi murisi commented Apr 22, 2024

In the course of hardware wallet implementation, it became apparent that value commitment randomness needs to be communicated to the hardware in order to allow the signing of MASP transactions in one round. This PR addresses this by exposing the randomness that was used to create value commitments in the spend, convert, and output descriptions. More precisely, it does this by extending the SaplingMetadata section to include spend_rcvs: Vec<jubjub:Fr>, convert_rcvs: Vec<jubjub:Fr>, and output_rcvs: Vec<jubjub:Fr> vectors that map positions in the description vectors to the randomness used to generate their value commitment.

@murisi murisi force-pushed the murisi/expose-randomness branch from 2e3a3ac to fa4a51f Compare April 22, 2024 12:40
@murisi murisi requested a review from XuyangSong April 22, 2024 12:40
@murisi murisi force-pushed the murisi/expose-randomness branch 2 times, most recently from 19d3565 to 5512c53 Compare April 22, 2024 12:49
@murisi murisi requested review from grarco and cwgoes April 22, 2024 12:50
@murisi murisi force-pushed the murisi/expose-randomness branch from 5512c53 to e423e98 Compare April 22, 2024 12:54
@murisi murisi force-pushed the murisi/expose-randomness branch from e423e98 to b5f570f Compare April 22, 2024 13:11
@murisi murisi mentioned this pull request Apr 22, 2024
2 tasks
Copy link
Contributor

@XuyangSong XuyangSong left a comment

Choose a reason for hiding this comment

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

The randomness is already set back to the SaplingProvingContext as the bsk, right? Do we still need to explicitly expose it from spend/output/convert_proof function?
I might not have the right background. It seems like you want to rebuild the value commitments somewhere else, so you need to expose all the randomness?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants