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
Integrate Orchard into Unified Address types #5569
Integrate Orchard into Unified Address types #5569
Conversation
8c3cb7d
to
1fa9482
Compare
Co-authored-by: Jack Grigg <jack@z.cash>
1a41c57
to
454db83
Compare
Force-pushed to add a few missing pieces to the "add Orchard to UAs" and "add Orchard to UFVKs" commits. |
454db83
to
e9810d7
Compare
CDataStream ss(data, SER_NETWORK, PROTOCOL_VERSION); | ||
auto key = libzcash::OrchardFullViewingKey::Read(ss); | ||
EXPECT_EQ(key, orchardKey); | ||
} | ||
// Enable the following after Orchard keys are supported. |
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.
Should this still be disabled? If it should, add a reference to the relevant issue.
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 test is checking that constructing a UFVK from the same seed as the test vectors gives the same receivers, but the final overall check cannot be enabled without us having a way to construct a UFVK manually with an unknown component, because the test vectors chose to include an unknown component that by definition we cannot derive. Adding that API is out of scope for this PR.
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.
We should modify the test vectors to also generate the UA that contains only the known receiver types.
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.
Why not do this check only for the UAs without unknown components?
@@ -576,7 +576,8 @@ std::optional<libzcash::ZcashdUnifiedSpendingKey> | |||
throw std::runtime_error("CWallet::GenerateUnifiedSpendingKeyForAccount(): Failed to add Sapling change address to the wallet."); | |||
}; | |||
|
|||
// TODO ORCHARD: Add Orchard component to the wallet | |||
// Add Orchard spending key to the wallet | |||
orchardWallet.AddSpendingKey(usk.value().GetOrchardKey()); |
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.
To clarify, this change means that z_getnewaccount
will start storing the Orchard component in memory, but this PR is not exposing this fact in z_getnewaccount
or allowing Orchard-containing UAs to be derived. Those changes will be made in a subsequent PR.
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.
Flushing comments.
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.
Flushing more comments.
auto ufvkpair = wallet.GenerateNewUnifiedSpendingKey(); | ||
auto ufvk = ufvkpair.first; | ||
auto account = ufvkpair.second; | ||
uaResult = wallet.GenerateUnifiedAddress(account, {ReceiverType::P2PKH, ReceiverType::Sapling}); |
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.
Can this test Orchard yet?
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.
Not yet; that will be in a successor PR that @str4d is working on.
Co-authored-by: Jack Grigg <jack@z.cash>
Co-authored-by: Jack Grigg <jack@z.cash>
Orchard spending keys now live exclusively on the Rust side, and will be serialized there as part of the Orchard wallet serialization.
The only place we were using the returned Unified Spending Key was in a test, where we immediately converted it to a UFVK. Co-authored-by: Kris Nuttycombe <kris@nutty.land>
e9810d7
to
d099e46
Compare
Force-pushed to fix review comments, and add a missing handling of the Orchard component of a type conversion that was causing tests to fail. I'll push a separate commit to make the change to how UFVKs are looked up from Sapling addresses (to have it match Orchard). |
This ensures we have the same semantics for detecting Orchard and Sapling receivers in UAs, even if the UA they are part of was derived outside of the zcashd wallet.
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.
Two minor issues.
auto ufvkpair = wallet.GenerateNewUnifiedSpendingKey(); | ||
auto ufvk = ufvkpair.first; | ||
auto account = ufvkpair.second; | ||
uaResult = wallet.GenerateUnifiedAddress(account, {ReceiverType::P2PKH, ReceiverType::Sapling}); |
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.
Not yet; that will be in a successor PR that @str4d is working on.
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.
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.
utACK
This PR enables
z_getnewaccount
to produce accounts that support Orchard-containing UAs, but does not add support for generating those UAs.Closes #5255.
Closes #5394.