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 ELIP-deterministic-descriptor-blinding-key module #61

Conversation

LeoComandini
Copy link
Contributor

Reference implementation for ElementsProject/ELIPs#8

@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch 4 times, most recently from bf28d9b to e3b775c Compare November 23, 2023 07:43
@LeoComandini LeoComandini changed the title WIP: Add ELIP-deterministic-descriptor-blinding-key module Add ELIP-deterministic-descriptor-blinding-key module Nov 23, 2023
@LeoComandini
Copy link
Contributor Author

Implementing FromStr for "ct(elipxxxx,DESC)" (ie with "elipxxxx" instead of the actual key) is a bit tricky because of the network.
View keys are in WIF format which includes the (bitcoin) network.
I think we have 3 options:

  • (1) we give up on implementing FromStr for ConfidentialDescriptors with "elipxxxx" as view key string
  • (2) we implement FromStr for (ConfidentialDescriptor, Network)
  • (3) we implement FromStr for ConfidentialDescriptor deducing the network from the ordinary decriptor (which we can do if eg it has one xpub), if no network can be deduced, we default to eg mainnet.

Anyway independently from the choice this will be a separate commit, and perhaps a separate PR.

@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch from e3b775c to 358f663 Compare November 23, 2023 09:28
@apoelstra
Copy link
Member

Is there any way we can change the viewkey format from WIF (which includes a network) to hex? Or to bech32 with a custom viewkey/elipxxx/whatever prefix?

@LeoComandini
Copy link
Contributor Author

Is there any way we can change the viewkey format from WIF (which includes a network) to hex? Or to bech32 with a custom viewkey/elipxxx/whatever prefix?

I think that implies amending ELIP-150. Which I'm supportive of, and I think we're still in time to do it.

@apoelstra
Copy link
Member

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.

@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch from 358f663 to d79708b Compare November 24, 2023 06:09
@LeoComandini
Copy link
Contributor Author

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.

ELIP changes: ElementsProject/ELIPs#9

Reference impl changes: #64

@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch from d79708b to 7a32381 Compare November 28, 2023 15:42
@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch from 7a32381 to d2e8b26 Compare December 21, 2023 11:41
Implementation for deterministic descriptor blinding keys.
@LeoComandini LeoComandini force-pushed the 2023-11-17-deterministic-descriptor-blinding-key branch from d2e8b26 to 34005bc Compare January 3, 2024 08:00
Ok(Key::View(DescriptorSecretKey::Single(SinglePriv {
origin: None,
key: bitcoin::key::PrivateKey::new(secret_key, network),
})))
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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 :)

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 34005bc

@apoelstra apoelstra merged commit 259f7c4 into ElementsProject:master Jan 9, 2024
18 checks passed
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