-
Notifications
You must be signed in to change notification settings - Fork 14
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 ELIP-deterministic-descriptor-blinding-key module #61
Add ELIP-deterministic-descriptor-blinding-key module #61
Conversation
bf28d9b
to
e3b775c
Compare
Implementing
Anyway independently from the choice this will be a separate commit, and perhaps a separate PR. |
e3b775c
to
358f663
Compare
Is there any way we can change the viewkey format from WIF (which includes a network) to hex? Or to bech32 with a custom |
I think that implies amending ELIP-150. Which I'm supportive of, and I think we're still in time to do it. |
I think we should. Having network bytes inside descriptors is a huge pain and I definitely didn't intend to cause that to happen. It is Thanksgiving here and I should not be at work :) but happy to review/merge such a change next week, if it makes sense on your end. |
358f663
to
d79708b
Compare
ELIP changes: ElementsProject/ELIPs#9 Reference impl changes: #64 |
d79708b
to
7a32381
Compare
7a32381
to
d2e8b26
Compare
Implementation for deterministic descriptor blinding keys.
d2e8b26
to
34005bc
Compare
Ok(Key::View(DescriptorSecretKey::Single(SinglePriv { | ||
origin: None, | ||
key: bitcoin::key::PrivateKey::new(secret_key, network), | ||
}))) |
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 34005bc:
Can you remind me why we would've had trouble parsing WIF with a network here? (I don't think we should support WIF anyway for various reasons, but I'm curious now.)
Otherwise ACK.
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 main issue is converting ct(elip151,desc)
to ct(key,desc)
where key
is the actual view key.
If we use WIF, we should deduce the network from desc
which however it might not be possible (eg if desc
has only single public keys).
There are other options to handle the conversion, but we decided to go for the "hex" solution.
These were discussed here #61 (comment)
Other issues with WIF are that we might have mismatching network between the descriptor blinding key and the ordinary descriptor, and that single pub keys have no network, while single priv keys in WIF have a network so it's somehow inconsistent.
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.
Ok, the conversion thing makes sense, thanks!
The other issues, about mismatching networks etc., we have to deal with anyway with xprivs and xpubs. I think that most software "deals with it" by just ignoring the network bytes :)
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.
ACK 34005bc
Reference implementation for ElementsProject/ELIPs#8