-
Notifications
You must be signed in to change notification settings - Fork 23
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
Unify keys #1414
Unify keys #1414
Conversation
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 all appears to be on the write track! (pardon the pun)
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.
From a careful readthrough of the new read/write methods, I believe them to be correct.
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.
I'm worried I'll lose github state if I leave this review open, so here's an incomplete review! I'll be back for that last file
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.
I don't have strong objections to this PR. Over all is a good improvement. There are existing code smell on critical areas that could be improved given the opportunity and them not being big changes.
nice work
… FVK logic for transparent address generation
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.
did not test but looks good to me.
I have sanity tested this version locally. |
Problem
Previously zingolib derived an externally scoped BIP32/44 key, and used that as its transparent key. This architecture was not flexible enough to handle the new ephemeral scope, specified in ZIP320.
Solution
This upgrades the
WalletCapability
to use a keystore backed by a UnifiedSpendingKey/UnifiedFullViewingKey which also includes a fully ZIP320 compliant transparent key type.Capability
withUnifiedKeyStore
inWalletCapability
Capability
to legacy and removes unecessary impls no longer neededWalletKind
command due to removal ofkind_str()
new_address()
to also derive scope with alegacy_key
bool for loading old wallet versions with external scope already derivedKeyError
for improving error handlingWrite()
inReadableWriteable
trait so chain type can be passed for writing UnifiedFullViewingKeysread_internal()
after keystore is updated