-
Notifications
You must be signed in to change notification settings - Fork 2k
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 unified addresses to the zcashd wallet. #5395
Add unified addresses to the zcashd wallet. #5395
Conversation
d77c489
to
a47ae76
Compare
12c8dcb
to
de6ac67
Compare
316e02d
to
66837af
Compare
de1d41b
to
c908a3b
Compare
20e1614
to
c6289cd
Compare
7e859f4
to
bbe3d87
Compare
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 review comments.
UnifiedAddress ua; | ||
|
||
if (saplingKey.has_value()) { | ||
if (saplingKey.has_value() && receiverTypes.count(ReceiverType::Sapling) > 0) { |
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.
In the PR that connects this logic to the z_getaddressforaccount
RPC method, the latter's help text needs to document that "unsupported" receiver types for this account (e.g. if the account was generated before some future shielded protocol was added to zcashd
) will be ignored, i.e. the returned UA will contain the largest subset of the specified receiver types that it can support. (This behaviour might change in future, if e.g. we decide to automatically add future shielded pools to existing accounts, but doing so is compatible with this documentation.)
6cd46ad
to
aaf48b0
Compare
aaf48b0
to
7adc6ef
Compare
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.
The ordering of items for the ID is blocking. Otherwise utACK.
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.
In addition to my comments, I notice that zcash-gtest
failed on three of seven CI workers, which seems statistically significant (but the error logs have been garbage-collected from Tekton).
f9e1894
to
c532257
Compare
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 c532257bbdee1c2d8780457a0dd526d2b8b59683 modulo the return value issue below (which is technically fine as-is because it will always return true
AFAICT).
93a0c19
to
dda30ba
Compare
ZcashdUnifiedFullViewingKey::FindAddress was previously not checking that the transparent child index did not overflow in unified address generation. GenerateUnifiedAddress has been modified to search from the last known diversifier index if no diversifier is specified, and boundary conditions for transparent addresses are now correctly handled.
Co-authored-by: str4d <jack@electriccoin.co>
dda30ba
to
eb53abb
Compare
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.
re-utACK eb53abb
|
||
diversifier_index_t j; | ||
// If the wallet is missing metadata at this UFVK id, it is probably | ||
// corrupt and the node should shut down. |
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 a std::out_of_range
exception here actually shut the node down in all calling contexts?
We normally minimize the use of exceptions because of the difficulty of answering questions like that (and because we've had past cases in which an exception was caught and the node proceeded with inconsistent state).
} | ||
|
||
// If the wallet is missing metadata at this UFVK id, it is probably | ||
// corrupt and the node should shut down. |
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 a std::out_of_range
exception here actually shut the node down in all calling contexts?
@@ -281,37 +280,48 @@ CPubKey CWallet::GenerateNewKey() | |||
BIP44CoinType(), | |||
ZCASH_LEGACY_ACCOUNT).value(); | |||
|
|||
std::optional<std::pair<CExtKey, HDKeyPath>> extKey = std::nullopt; | |||
std::optional<std::pair<CKey, HDKeyPath>> extKey = std::nullopt; |
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.
The variable is still called extKey
even though it no longer is. (I'm assuming that ext
stood for extended
rather than external
.)
* Returns `true` if this is a new entry or if the operation would not | ||
* alter the existing set of receiver types at this index, `false` | ||
* otherwise. |
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 is it useful to return true
in those two cases?
} | ||
|
||
/** | ||
* Search the for the maximum diversifier that has already been used to |
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.
* Search the for the maximum diversifier that has already been used to | |
* Search for the the maximum diversifier that has already been used to |
Fixes #5179