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

add SigningParts getters #433

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

conradoplg
Copy link

Depends on #428

See #430 for rationale

@conradoplg conradoplg force-pushed the signing-parts-getters branch from 5b611bf to f0c88b7 Compare January 21, 2025 14:54
Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

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

Not including this PR in orchard 0.11.0

@@ -334,6 +334,15 @@ impl From<FullViewingKey> for SpendValidatingKey {
}

impl FullViewingKey {
/// Create FVK from the given sk and ak.
pub fn from_sk_ak(sk: &SpendingKey, ak: SpendValidatingKey) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

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

The documentation here is very insufficient:

  • It makes no mention of how sk and ak are checked or combined (in particular, that you get a different FVK than if you just go from sk).
  • It makes no mention of FROST (or why you would want to use this API).
  • It is not behind a feature flag so is exposing a normative public API which I do not want to be present without a corresponding specification (which will eventually be ZIP 312 once [ZIP 312] Key generation zips#883 is finished).

Also, not documented as an addition in the changelog.

&self.ak
}
/// Return the randomization for this action.
pub fn alpha(&self) -> pallas::Scalar {
Copy link
Contributor

Choose a reason for hiding this comment

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

These getters are only necessary for the older compile-time state machine builder API. Since this PR was opened, we've deployed PCZTs which already include these getters implicitly, and PCZTs (and runtime state machine builder APIs in general) are the general direction we will be heading, so these aren't technically necessary. That being said, as these are behind an unstable feature flag I wouldn't mind them going in for testing purposes, on the understanding that they likely will eventually be removed (along with the corresponding builder logic).

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.

2 participants