Implement `GetKey` for `KeyMap` #765

tcharding · 2024-10-29T01:22:37Z

Create a KeyMap type to replace the current BTreeMap alias and implement bitcoin::psbt::GetKey for it.

Close: #709

tcharding · 2024-10-29T01:31:37Z

apoelstra · 2024-10-29T12:23:45Z

Nice! Yeah, this is probably the right approach.

In 00342a1 you have a bunch of unreachables because you assume that public keys map consistently to secret keys. I think this is a reasonable assumption, but you need to enforce it in the insert method. Or perhaps you could change insert to just take a secret key, and do the pubkey computation itself.

Alternately, you could make insert be non-pub so that the type can only be constructed by calling Descriptor::parse_descriptor. This might be the better approach. (Though in this case I'd still add an assertion to insert checking consistency of the public and secret keys.)i

LLFourn · 2024-10-30T00:00:08Z

Thanks @tcharding. It might be nice to be able to append your key maps onto each other so you keep one big jumble of secret keys across all your descriptors in the application. This is possible now but would be harder to do if you make the field private (which does seem like the right thing in general). So maybe an .extend with another keymap. If you make it private you probably want to make a way to iterate it too.

tcharding · 2024-10-30T00:28:58Z

Yes I threw the pub inner field so as not to have to implement the whole BTreeMap API but private inner is probably better as you say - I can do this now we a have loose concept ack.

ValuedMammal · 2024-11-07T21:36:46Z

Concept ACK

sanket1729 · 2024-11-11T07:28:27Z

It might be nice to be able to append your key maps onto each other so you keep one big jumble of secret keys across all your descriptors in the application.

Maybe in the longer term, a cleaner solution is to implement rust-bitcoin to implement GetKey for a tuple, vec, set of things that already implement GetKey.

impl_get_key_tuple!((T1, T2))
impl GetKey for Vec<T> where T: GetKey {
}
impl GetKey for BtreeSet<T>...

sanket1729 · 2024-11-11T07:29:05Z

Concept ACK.

tcharding · 2024-12-12T23:41:19Z

Implemented iter::IntoIterator and iter::Extend, would love someone else to give a few minutes to thinking if this is all of the iterator traits we need please.

Also made new take only the secret key. I did not remove any unreachable calls, nor did I add an assertion on the pk/sk since pk in insertion is now controlled.

Copilot

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

src/descriptor/key_map.rs:143

The use of the unreachable! macro can be problematic if assumptions change. Consider handling this case more gracefully.

unreachable!("XPrv maps to XPrv")

src/descriptor/key_map.rs:22

[nitpick] The name KeyMap is quite generic. Consider renaming it to something more descriptive like DescriptorKeyMap.

pub struct KeyMap {

Copilot · 2024-12-16T17:06:58Z

src/descriptor/key_map.rs

+                            if pk == request {
+                                match v {
+                                    DescriptorSecretKey::Single(ref sk) => Some(sk.key),
+                                    _ => unreachable!("Single maps to Single"),


The use of the unreachable! macro can be problematic if assumptions change. Consider handling this case more gracefully.

Suggested change

_ => unreachable!("Single maps to Single"),

_ => return Err(GetKeyError::InvalidKey),

AI is so awesome I think we are all going to be out of a job soon.

Not if your job is to have fun :)

Copilot · 2024-12-16T17:06:59Z

src/descriptor/key_map.rs

+                                            None
+                                        }
+                                    }
+                                    _ => unreachable!("XPrv maps to XPrv"),


The use of the unreachable! macro can be problematic if assumptions change. Consider handling this case more gracefully.

Copilot · 2024-12-16T17:06:59Z

src/descriptor/key_map.rs

+                                    DescriptorSecretKey::MultiXPrv(xpriv) => {
+                                        Some(xpriv.xkey.to_priv())
+                                    }
+                                    _ => unreachable!("MultiXPrv maps to MultiXPrv"),


The use of the unreachable! macro can be problematic if assumptions change. Consider handling this case more gracefully.

apoelstra · 2024-12-16T17:15:16Z

Too bad. copilot has been around long enough that you'd think it would work, but 100% of its suggestions are wrong and it's full of irritating woke language like "harmful" and "problematic".

apoelstra · 2024-12-16T17:23:37Z

src/descriptor/key_map.rs

+        Ok(self.map.iter().find_map(|(k, v)| {
+            match k {
+                DescriptorPublicKey::Single(ref pk) => match key_request {
+                    KeyRequest::Pubkey(ref request) => match pk.key {


In d2c954a:

I think if you replace

match k { Thing => match key_request { Thing2 => ...

with

match (k, key_request) { (Thing, Thing) => {

you can reduce the amount of indentation and should be able to reduce the number of branches.

Yes, at least it looks better. I tried this, see: oleonardolima@4f304d1

sanket1729 · 2024-12-16T17:30:10Z

Too bad. copilot has been around long enough that you'd think it would work, but 100% of its suggestions are wrong and it's full of irritating woke language like "harmful" and "problematic".

:) . Still too far. Let's try it in another 6 months.

sanket1729 · 2024-12-16T17:32:39Z

@apoelstra @tcharding wdyt about #765 (comment)? I think that would solve future API requests like extend, merge etc

apoelstra · 2024-12-16T18:33:40Z

Maybe in the longer term, a cleaner solution is to implement rust-bitcoin to implement GetKey for a tuple, vec, set of things that already implement GetKey.

concept ACK, though we haven't really looked at GetKey upstream with an eye to 1.0. Unsure what the trait will look like when we do.

tcharding · 2025-04-27T23:26:13Z

FTR I had totally forgotten about this PR until @ValuedMammal tagged me. I tried but am unable to engage my brain right now to implement the review suggestion from Andrew (#765 (comment)).

tcharding · 2025-04-27T23:27:48Z

@apoelstra @tcharding wdyt about #765 (comment)? I think that would solve future API requests like extend, merge etc

I have no opinion ATM sorry mate simply because I haven't managed to context switch into miniscript properly right now.

oleonardolima · 2025-06-02T19:35:46Z

@tcharding I've been working on similar changes for bitcoindevkit/bdk_wallet#70 in bitcoindevkit/bdk_wallet#235, and I can continue the initial work from here and open another candidate PR. Is that fine?

I discussed with @ValuedMammal, and it seems that we could implement the GetKey for DescriptorSecretKey instead. Any previous thoughts on this?

tcharding · 2025-06-03T07:16:27Z

I've no real opinion mate, I don't work much on miniscript. I actually don't even know if this PR can go in or requires changes.

apoelstra · 2025-06-03T14:19:05Z

src/descriptor/key_map.rs

+    ) -> Result<DescriptorPublicKey, DescriptorKeyParseError> {
+        let pk = sk.to_public(secp)?;
+        if !self.map.contains_key(&pk) {
+            self.map.insert(pk.clone(), sk);


In d2c954a:

Both the contains_key check and the clone are unnecessary here.

I had a dig and the BTreeMap::insert is a little different to this one because the value in the map can differ but because our map is mapping pk to sk it cannot, right? If that assumption is correct then I believe the code is correct if we want to unconditionally return the public key.

Oh, yeah, the clone may be necessary.

But the check isn't doing anything except a pointless lookup.

apoelstra · 2025-06-03T14:21:14Z

src/descriptor/key_map.rs

+                            }
+                            _ => unreachable!("XPrv maps to XPrv"),
+                        },
+                        _ => unreachable!("rust-bitcoin v0.32"),


In d2c954a:

This might not be unreachable for every version of 0.32.x. You should just return None here.

I was very confused by what was in this PR until I found rust-bitcoin/rust-bitcoin#4238

I've returned None as suggested and added a TODO because I think we can support XOnlyPublicKey look up as well, right? I'm not familiar enough with the codebase and not sharp enough right now to work it out. If this requires any thought on your part just say and I'll come back and think harder.

Also are you ok with TODO in the codebase here in miniscript or would you prefer an issue?

Fine to have a TODO in the codebase.

Create a `KeyMay` type to replace the current `BTreeMap` alias and implement `bitcoin::psbt::GetKey` for it. Close: rust-bitcoin#709

oleonardolima · 2025-06-05T12:26:57Z

src/descriptor/key_map.rs

+                            DescriptorSecretKey::XPrv(xpriv) => {
+                                // This clone goes away in next release of rust-bitcoin.
+                                if let Ok(Some(sk)) = xpriv.xkey.get_key(key_request.clone(), secp)
+                                {
+                                    Some(sk)
+                                } else {
+                                    None
+                                }


The existing get_key implementation for Xpriv does not cover the scenario when the KeyRequest::Bip32(..) uses the key origin information, and it'd need to be covered here (it's a scenario that's being tested by BDK).

I handled it this way in my implementation, see: oleonardolima@4f304d1#diff-9b4da42f4bda05e0c63a0bae838b0eae32dfc2d5511a0c8142db8acfa9337aa2R142-R160 it's tested by oleonardolima@4f304d1#diff-9b4da42f4bda05e0c63a0bae838b0eae32dfc2d5511a0c8142db8acfa9337aa2R391-R422

oleonardolima · 2025-06-05T12:27:06Z

src/descriptor/key_map.rs

+        Ok(self.map.iter().find_map(|(k, v)| {
+            match k {
+                DescriptorPublicKey::Single(ref pk) => match key_request {
+                    KeyRequest::Pubkey(ref request) => match pk.key {


Yes, at least it looks better. I tried this, see: oleonardolima@4f304d1

tcharding · 2025-06-06T08:53:26Z

Thanks for the review @oleonardolima, I'll look into your suggestions.

tcharding force-pushed the 10-29-key-map branch 2 times, most recently from ba5b2bf to 4a3bd7e Compare October 29, 2024 01:31

tcharding force-pushed the 10-29-key-map branch 2 times, most recently from 81b4923 to 00342a1 Compare October 29, 2024 02:25

notmandatory mentioned this pull request Dec 1, 2024

Remove signers from bdk_wallet bitcoindevkit/bdk_wallet#70

Open

5 tasks

tcharding force-pushed the 10-29-key-map branch from 00342a1 to 4920626 Compare December 12, 2024 23:36

tcharding force-pushed the 10-29-key-map branch 2 times, most recently from a97c37a to d2c954a Compare December 13, 2024 00:19

sanket1729 requested a review from Copilot December 16, 2024 17:06

Copilot AI reviewed Dec 16, 2024

View reviewed changes

apoelstra reviewed Dec 16, 2024

View reviewed changes

ValuedMammal mentioned this pull request Dec 18, 2024

chore: should we remove unused SignerError variants ? bitcoindevkit/bdk_wallet#93

Open

ValuedMammal mentioned this pull request Apr 27, 2025

The new TxBuilder bitcoindevkit/bdk-tx#1

Merged

4 tasks

apoelstra reviewed Jun 3, 2025

View reviewed changes

Implement GetKey for KeyMap

4a3c350

Create a `KeyMay` type to replace the current `BTreeMap` alias and implement `bitcoin::psbt::GetKey` for it. Close: rust-bitcoin#709

tcharding force-pushed the 10-29-key-map branch from d2c954a to 4a3c350 Compare June 5, 2025 07:29

oleonardolima reviewed Jun 5, 2025

View reviewed changes

	_ => unreachable!("Single maps to Single"),
	_ => return Err(GetKeyError::InvalidKey),

Implement GetKey for KeyMap #765

Are you sure you want to change the base?

Implement GetKey for KeyMap #765

Uh oh!

Conversation

tcharding commented Oct 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tcharding commented Oct 29, 2024

Uh oh!

apoelstra commented Oct 29, 2024

Uh oh!

LLFourn commented Oct 30, 2024

Uh oh!

tcharding commented Oct 30, 2024

Uh oh!

ValuedMammal commented Nov 7, 2024

Uh oh!

sanket1729 commented Nov 11, 2024

Uh oh!

sanket1729 commented Nov 11, 2024

Uh oh!

tcharding commented Dec 12, 2024

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 16, 2024

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 16, 2024

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 16, 2024

Choose a reason for hiding this comment

Uh oh!

apoelstra commented Dec 16, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sanket1729 commented Dec 16, 2024

Uh oh!

sanket1729 commented Dec 16, 2024

Uh oh!

apoelstra commented Dec 16, 2024

Uh oh!

tcharding commented Apr 27, 2025

Uh oh!

tcharding commented Apr 27, 2025

Uh oh!

oleonardolima commented Jun 2, 2025

Uh oh!

tcharding commented Jun 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Implement `GetKey` for `KeyMap` #765

Implement `GetKey` for `KeyMap` #765

tcharding commented Oct 29, 2024 •

edited

Loading

tcharding Jun 5, 2025 •

edited

Loading