descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` #31243

achow101 · 2024-11-07T16:56:35Z

Instead of having MakeScripts infer what pubkeys need to go into the output FlatSigningProvider, have each of the PubkeyProviders that have GetPubKey and GetPrivKey called fill it directly with relevant keys and origins.

This allows for keys and origins to be added that won't directly appear in the output, which is necessary for musig() descriptors.

Split from #29675

DrahtBot · 2024-11-07T16:56:38Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31243.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	fjahr, theStack, rkrux
Concept ACK	Sjors

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#31244 (descriptors: MuSig2 by achow101)
#29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101)
#28710 (Remove the legacy wallet and BDB dependency by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

theStack

Code-review ACK f50470e33c1bb51531f3fa08f6d29c54df304d6b

To my understanding, the second and fourth commits (db270fa2a33d7c88e58682ab8a219a2e70503c9e and f50470e33c1bb51531f3fa08f6d29c54df304d6b) are pure refactors, while the third one actually changes behaviour for Descriptor::Expand call-sites w.r.t. by returning more public key data than before (stored in the FlatSigningProvider& out parameter), so the first commit (d1be90704559da45e4d76171230ecb9f4a6d9cf8) is needed to avoid breaking the importmulti RPC call behaviour. Without that, the "Imported scripts with pubkeys should not have their pubkeys go into the keypool" sub-test in wallet_importmulti.py fails.

src/script/descriptor.cpp

src/script/descriptor.h

theStack

re-ACK 186bc75985a0afa96eba3c5bfea09e22fe3ec2c8 🗒️

fjahr

Apparently I started to review and got pinged now because of the rebase message. Leaving these nits here in case you want to address them in the rebase. Will look at this again soon.

fjahr · 2024-12-30T15:25:48Z

src/wallet/rpc/backup.cpp

nit: Could add a comment here as well, something like

Suggested change

bool can_keypool = parsed_descs.at(0)->IsSingleKey();

// Only single key descriptors are allowed to be imported into a legacy wallet's keypool

bool can_keypool = parsed_descs.at(0)->IsSingleKey();

This^ has been resolved now.

fjahr · 2024-12-30T15:26:19Z

src/script/descriptor.cpp

nit: Typo in 7c614b15bc31a7d6f7daaa48c046eb2c7cca697e description “or now”

Sjors

Concept ACK

Mostly happy with 1bfabb4, but I'm confused about the key origin handling.

Sjors · 2025-01-30T13:35:11Z

src/script/descriptor.cpp

-    /** Derive a private key, if private data is available in arg. */
-    virtual bool GetPrivKey(int pos, const SigningProvider& arg, CKey& key) const = 0;
+    /** Derive a private key, if private data is available in arg and put it into out. */
+    virtual void GetPrivKey(int pos, const SigningProvider& arg, FlatSigningProvider& out) const = 0;


1bfabb4: maybe rename to FillPrivKey?

/** Try to derive the private key at pos, if private data is available in arg, and fill out with it. */ virtual void FillPrivKey(int pos, const SigningProvider& arg, FlatSigningProvider& out) const = 0;

That also distinguishes it from ConstPubkeyProvider::GetPrivKey.

The verb "fill" suggests to me that the caller is filling the descriptor with a private key, rather than the descriptor filling something else. I think "Get" is still appropriate.

I am inclining to agree with @achow101 here. Although I don't like a function that is prefixed with Get returning nothing but at the moment it's a common pattern in the codebase to Get something and update a reference passed in one of the function arguments. The confusion, as highlighted above, that might arise with prefixing with Fill makes me not to want to use that.

Sjors · 2025-01-30T13:51:01Z

src/script/descriptor.cpp

     *  Caches are not exclusive but this is not tested. Currently we use them exclusively
     */
-    virtual bool GetPubKey(int pos, const SigningProvider& arg, CPubKey& key, KeyOriginInfo& info, const DescriptorCache* read_cache = nullptr, DescriptorCache* write_cache = nullptr) const = 0;
+    virtual std::optional<CPubKey> GetPubKey(int pos, const SigningProvider& arg, FlatSigningProvider& out, const DescriptorCache* read_cache = nullptr, DescriptorCache* write_cache = nullptr) const = 0;


e743d11: maybe rename this to FillPubKey. The filling seems more important, and the return value makes it clear enough it also gets it.

In the function doc:

-/** Derive a public key. +/** Derive a public key and put it into `out`

Added the comment.

Sjors · 2025-01-30T14:25:56Z

src/script/descriptor.cpp

+        std::optional<CPubKey> pub = m_provider->GetPubKey(pos, arg, out, read_cache, write_cache);
+        if (!pub) return std::nullopt;
+        auto& [pubkey, suborigin] = out.origins[pub->GetID()];
+        Assert(pubkey == *pub); // All subproviders must be inserting a valid origin already


e743d11: I'm confused by this comment. I guess by "valid" you mean that a KeyOriginInfo field is present, but it can be a dummy?

It seems more intuitive if we insert an origin entry ourselves here ... if possible.

Valid means that the origin is correct. It may not be useful, e.g. the origin of a random key is itself, but it's valid and correct.

fjahr

Concept ACK

Everything besides my GetPrivKey question looks good to me. Will do a final pass once I get an answer there.

fjahr · 2025-02-01T21:00:19Z

src/script/descriptor.cpp

    CPubKey m_pubkey;
    bool m_xonly;

+    std::optional<CKey> GetPrivKey(const SigningProvider& arg) const


Hm, I am not seeing why having two GetPrivKeys is better than one. The description of the commit only talks about the other one, not this one. For this one the caller still cares about the return value it seems. Can't they be unified under the std::optional returning variant? It seems like the variant using FlatSigningProvider is just used in one place in ExpandPrivate and the whole benefit is saving us one line there.

The benefit is in the MuSig2 PRs where GetPrivKey can insert multiple private keys to the FlatSigningProvider, none of which are the private key for the MuSig2 aggregate pubkey itself.

For the ConstPubkeyProvider, it's useful to have another GetPrivKey that returns the single private key since this is behavior is used in a few places within this class's member functions. None of the other pubkey providers need this.

Understood. I think I would have chosen a different name for the one in ConstPubkeyProvider, like GetConstPrivKey maybe, but completely optional.

The benefit is in the MuSig2 PRs where GetPrivKey can insert multiple private keys to the FlatSigningProvider, none of which are the private key for the MuSig2 aggregate pubkey itself.

Something around this can be mentioned either in the commit message and/or the PR description.

like GetConstPrivKey maybe

This is already inside ConstPubkeyProvider class, using Const again could feel repetitive. I think the function overloading (with different argument types) is differentiating enough. Though, some documentation for the new function would be helpful for the reader.

Something around this can be mentioned either in the commit message and/or the PR description.

Added to the commit message.

theStack

re-ACK 1bfabb4

src/script/descriptor.h

src/script/descriptor.cpp

fjahr · 2025-03-05T20:04:42Z

utACK 1bfabb4

rkrux

Few initial comments, I would like to spend more time on this PR to complete the review.

src/script/descriptor.cpp

rkrux · 2025-03-06T12:30:23Z

src/script/descriptor.cpp

     *  Caches are not exclusive but this is not tested. Currently we use them exclusively
     */
-    virtual bool GetPubKey(int pos, const SigningProvider& arg, CPubKey& key, KeyOriginInfo& info, const DescriptorCache* read_cache = nullptr, DescriptorCache* write_cache = nullptr) const = 0;
+    virtual std::optional<CPubKey> GetPubKey(int pos, const SigningProvider& arg, FlatSigningProvider& out, const DescriptorCache* read_cache = nullptr, DescriptorCache* write_cache = nullptr) const = 0;


In the function doc:

-/** Derive a public key. +/** Derive a public key and put it into `out`

src/script/descriptor.cpp

rkrux · 2025-03-06T13:02:40Z

src/script/descriptor.cpp

    CPubKey m_pubkey;
    bool m_xonly;

+    std::optional<CKey> GetPrivKey(const SigningProvider& arg) const


The benefit is in the MuSig2 PRs where GetPrivKey can insert multiple private keys to the FlatSigningProvider, none of which are the private key for the MuSig2 aggregate pubkey itself.

Something around this can be mentioned either in the commit message and/or the PR description.

rkrux · 2025-03-06T13:07:29Z

src/script/descriptor.cpp

        out.origins.emplace(keyid, std::make_pair(m_pubkey, info));
+        out.pubkeys.emplace(keyid, m_pubkey);


I agree with filling out with pubkeys and origins together in a function.

rkrux

Few comments, mostly LGTM.

src/wallet/rpc/backup.cpp

rkrux · 2025-03-08T15:25:35Z

src/script/descriptor.cpp

This comment is vaguely correct now, technically ok but doesn't gel well with the new object name, causes confusion. IMO best to update it.

Removed it, I don't think there's anything meaningfully useful to say in a comment here.

src/script/descriptor.cpp

rkrux · 2025-03-08T15:25:46Z

src/script/descriptor.cpp

Overall the update count (in this file atleast) of the members of the class FlatSigningProvider& out has decreased now because there are fewer PubkeyProviders and more DescrImpls , which IMO is desirable.

rkrux · 2025-03-08T15:25:54Z

src/script/descriptor.cpp

Coming from previous commit 070e746c2f72db2cc24b1c267b91fafbcc586736 and looking at this function as a whole, there's a lot going on.
Nit: A comment here would be quite helpful for the reader letting them know that origins & pubkeys are being appended.

I don't think a comment is necessary, emplace() is fairly self explanatory.

I realise my suggestion was not clear enough (and confusing). A comment can be present in the documentation of the function declaration instead - I have mentioned in another review comment: #31243 (comment)

src/script/descriptor.cpp

rkrux · 2025-03-10T10:41:55Z

src/script/descriptor.cpp

+1 for removing the usage of entries.back().first, entries.back().second as the output parameters to the GetPubKey(), which was not intuitive to read for me.

Legacy wallets should only import keys to the keypool if they came in a single key descriptor. Instead of relying on assumptions about the descriptor based on how many pubkeys show up after expanding the descriptor, explicitly mark descriptors as being single key type and use that for the check.

…bKey

Instead of having ExpandHelper fill in the origins in the FlatSigningProvider output, have GetPubKey do it by itself. This reduces the extra variables needed in order to track and set origins in ExpandHelper. Also changes GetPubKey to return a std::optional<CPubKey> rather than using a bool and output parameters.

Instead of MakeScripts inconsistently filling the output FlatSigningProvider with the pubkeys involved, just do it in GetPubKey.

Instead of GetPrivKey returning a key and having the caller fill the FlatSigningProvider, have GetPrivKey take the FlatSigningProvider and fill it by itself. This will be necessary for descriptors such as musig() where there are private keys that need to be added to the FlatSigningProvider but do not directly appear in any resulting scripts. GetPrivKey is now changed to void as the caller no longer cares whether it succeeds or fails.

rkrux

LGTM, code review acee5c5

Thank you for splitting the middle commit, makes it easier to review!

Broadly this pull updates the private & public key getters in the PubkeyProviders to also fill the passed SigningProvider out with the said keys; the effect of which is that it cleans the implementation of the call sites such as ExpandHelper in the Descriptors classes. This would result in more (than before) keys being set in the SigningProviders generally and the direct callers of these functions would need to accordingly adjust. I'm inclining to prefer the filling of the SigningProviders with the public key info (origin & key) together instead of having them filled in various functions like it was done previously.

There are few other minor improvements as well like highlighting the non-usage of the arguments in the function signature itself. I've started to look at the #29675 PR to find where the updated functionality of GetPrivKey is used as stated in the commit description.

Before I ack the PR, asked one question related to the first commit - #31243 (comment).

rkrux · 2025-04-16T12:14:18Z

src/wallet/rpc/backup.cpp

This^ has been resolved now.

rkrux · 2025-04-16T14:11:26Z

src/script/descriptor.cpp

        return true;
    }
-    bool GetPrivKey(int pos, const SigningProvider& arg, CKey& key) const override
+    void GetPrivKey(int pos, const SigningProvider& arg, FlatSigningProvider& out) const override


Nit: Because pos is unused.

- void GetPrivKey(int pos, const SigningProvider& arg, FlatSigningProvider& out) const override + void GetPrivKey(int, const SigningProvider& arg, FlatSigningProvider& out) const override

rkrux · 2025-04-16T14:27:33Z

src/script/descriptor.cpp

    }

-    /** Derive a public key.
+    /** Derive a public key and put it into out.


Nit:

- /** Derive a public key and put it into out. + /** Derive a public key and put it into out along with its origin info.

rkrux · 2025-04-16T14:29:11Z

src/script/descriptor.cpp

I realise my suggestion was not clear enough (and confusing). A comment can be present in the documentation of the function declaration instead - I have mentioned in another review comment: #31243 (comment)

rkrux · 2025-04-16T14:38:38Z

src/wallet/rpc/backup.cpp

            std::copy(scripts_temp.begin(), scripts_temp.end(), std::inserter(script_pub_keys, script_pub_keys.end()));
-            for (const auto& key_pair : out_keys.pubkeys) {
-                ordered_pubkeys.emplace_back(key_pair.first, desc_internal);
+            if (can_keypool) {


I'm looking at it after a month and have lost some context here.

What restriction in the previous code was disallowing the addition of public keys in the keypool for non-single-key type descriptors that made the "Imported scripts with pubkeys should not have their pubkeys go into the keypool" subtest pass? Sorry if this has been answered earlier but I didn't find it.

Prior to this PR, the multisig descriptors would not insert any pubkeys int out.pubkeys inside of MakeScripts. The pubkeys that are inserted to that FlatSigningProvider are the ones inserted into the keypool.

I see, they were being added for pkh, wpkh, combo, tr, miniscript ones in MakeScript but not for multisig & the like. I debugged this flow in on master while importing a multisig descriptor and found it quite strange that the origins of all the pubkeys involved in the multisig were being added in the out.origins inside ExpandHelper but not all the pubkeys were added in out.pubkeys!
Also, pubkeys being set inside MakeScript but origins being set in ExpandHelper made it difficult to reason about for me, the newer implementation makes it easier to follow.

bitcoinclireg importdescriptors '[{"desc": "wsh(multi(2,tprv8ZgxMBicQKsPdzuc344mDaeUk5zseMcRK9Hst8xodskNu3YbQG5NxLa2X17PUU5yXQhptiBE7F5W5cgEmsfQg4Y21Y18w4DJhLxSb8CurDf,tpubD6NzVbkrYhZ4YiCvExLvH4yh1k3jFGf5irm6TsrArY8GYdEhYVdztQTBtTirmRc6XfSJpH9tayUdnngaJZKDaa2zbqEY29DfcGZW8iRVGUY))#a0tl2jdn", "timestamp": "now"}]'

I used importdescriptors but the Expand flow is the same as in importmulti.

rkrux · 2025-04-16T15:13:33Z

src/script/descriptor.cpp

-    /** Derive a private key, if private data is available in arg. */
-    virtual bool GetPrivKey(int pos, const SigningProvider& arg, CKey& key) const = 0;
+    /** Derive a private key, if private data is available in arg and put it into out. */
+    virtual void GetPrivKey(int pos, const SigningProvider& arg, FlatSigningProvider& out) const = 0;


Not a suggestion, just thinking out loud.

For the sake of having a function signature consistent with the corresponding public key function - I suppose returning the private key from this function is not an option because we'd prefer to have fewer instances of private keys moving around within the codebase?

Though I'm wondering can there be an use case later where the caller would need to know whether the private key was gotten in which case the boolean return value is needed; seems a bit odd that the caller would need to find the key in the out every time even if they don't want to use the key.

fjahr

Code review ACK acee5c5

fjahr · 2025-04-18T11:58:44Z

src/script/descriptor.cpp

    /** Compare two public keys represented by this provider.
     * Used by the Miniscript descriptors to check for duplicate keys in the script.
     */
    bool operator<(PubkeyProvider& other) const {


nit: could make other const if you retouch

fjahr · 2025-04-18T12:02:53Z

LGTM, code review acee5c5

Was that an ACK an you just forgot the word or did you just want to say you reviewed? :)

theStack

re-ACK acee5c5

case-sensitivity yocto-nit: in commit subject for 6268bde: s/BIP32PUbKeyProvider/BIP32PubkeyProvider/

rkrux

ACK acee5c5

Was that an ACK an you just forgot the word or did you just want to say you reviewed? :)

I wanted to convey I code reviewed & almost ack. There was one thing that I had not completely reasoned about though it made sense to me intuitively somehow, so was hesitant in acking earlier: #31243 (comment)

rkrux · 2025-04-21T12:22:03Z

src/wallet/rpc/backup.cpp

            std::copy(scripts_temp.begin(), scripts_temp.end(), std::inserter(script_pub_keys, script_pub_keys.end()));
-            for (const auto& key_pair : out_keys.pubkeys) {
-                ordered_pubkeys.emplace_back(key_pair.first, desc_internal);
+            if (can_keypool) {


I see, they were being added for pkh, wpkh, combo, tr, miniscript ones in MakeScript but not for multisig & the like. I debugged this flow in on master while importing a multisig descriptor and found it quite strange that the origins of all the pubkeys involved in the multisig were being added in the out.origins inside ExpandHelper but not all the pubkeys were added in out.pubkeys!
Also, pubkeys being set inside MakeScript but origins being set in ExpandHelper made it difficult to reason about for me, the newer implementation makes it easier to follow.

bitcoinclireg importdescriptors '[{"desc": "wsh(multi(2,tprv8ZgxMBicQKsPdzuc344mDaeUk5zseMcRK9Hst8xodskNu3YbQG5NxLa2X17PUU5yXQhptiBE7F5W5cgEmsfQg4Y21Y18w4DJhLxSb8CurDf,tpubD6NzVbkrYhZ4YiCvExLvH4yh1k3jFGf5irm6TsrArY8GYdEhYVdztQTBtTirmRc6XfSJpH9tayUdnngaJZKDaa2zbqEY29DfcGZW8iRVGUY))#a0tl2jdn", "timestamp": "now"}]'

I used importdescriptors but the Expand flow is the same as in importmulti.

rkrux · 2025-04-21T12:28:20Z

src/script/descriptor.cpp

Probably in some follow up: The documentation of the MakeScripts function in DescriptorImpl class can be updated to get rid of the following line because the origin info is added in the GetPubKey functions now and was added in the ExpandHelper function previously.

The origin info of the provided pubkeys is automatically added.

achow101 force-pushed the descriptor-direct-fill branch from 6b91f7d to f50470e Compare November 7, 2024 17:11

This was referenced Nov 7, 2024

descriptors: MuSig2 #31244

Merged

wallet: Sign transactions containing MuSig2 inputs #31245

Closed

MuSig2 Tracking Issue #31246

Open

This was referenced Nov 8, 2024

wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys #29675

Merged

Remove the legacy wallet and BDB dependency #28710

Merged

theStack approved these changes Nov 17, 2024

View reviewed changes

src/script/descriptor.cpp Outdated Show resolved Hide resolved

src/script/descriptor.cpp Outdated Show resolved Hide resolved

src/script/descriptor.h Outdated Show resolved Hide resolved

achow101 force-pushed the descriptor-direct-fill branch from f50470e to 186bc75 Compare November 19, 2024 17:03

theStack approved these changes Nov 19, 2024

View reviewed changes

DrahtBot mentioned this pull request Dec 18, 2024

refactor: Use std::span over Span #31519

Merged

DrahtBot mentioned this pull request Jan 2, 2025

descriptors: Try pubkeys of both parities when retrieving the private keys for an xonly pubkey in a descriptor #31590

Merged

DrahtBot added the Needs rebase label Jan 21, 2025

fjahr reviewed Jan 21, 2025

View reviewed changes

achow101 force-pushed the descriptor-direct-fill branch from 186bc75 to 1bfabb4 Compare January 21, 2025 20:15

DrahtBot removed the Needs rebase label Jan 21, 2025

Sjors reviewed Jan 30, 2025

View reviewed changes

fjahr reviewed Feb 1, 2025

View reviewed changes

theStack approved these changes Feb 18, 2025

View reviewed changes

src/script/descriptor.h Outdated Show resolved Hide resolved

src/script/descriptor.cpp Outdated Show resolved Hide resolved

DrahtBot requested review from Sjors and fjahr February 18, 2025 16:37

rkrux reviewed Mar 6, 2025

View reviewed changes

achow101 force-pushed the descriptor-direct-fill branch 2 times, most recently from 4e0de38 to 72694b8 Compare March 6, 2025 17:28

DrahtBot mentioned this pull request Mar 10, 2025

[IBD] specialize block serialization #31868

Draft

rkrux reviewed Mar 10, 2025

View reviewed changes

DrahtBot added the Needs rebase label Mar 20, 2025

achow101 force-pushed the descriptor-direct-fill branch from 72694b8 to 2f28f28 Compare April 10, 2025 21:38

DrahtBot removed the Needs rebase label Apr 10, 2025

DrahtBot added CI failed Descriptors and removed CI failed labels Apr 11, 2025

achow101 added 5 commits April 14, 2025 16:32

descriptor: Remove unused parent_info from BIP32PUbKeyProvider::GetPu…

6268bde

…bKey

descriptors: Move FlatSigningProvider pubkey filling to GetPubKey

4b03031

Instead of MakeScripts inconsistently filling the output FlatSigningProvider with the pubkeys involved, just do it in GetPubKey.

achow101 force-pushed the descriptor-direct-fill branch from 2f28f28 to acee5c5 Compare April 14, 2025 23:32

rkrux reviewed Apr 16, 2025

View reviewed changes

fjahr reviewed Apr 18, 2025

View reviewed changes

DrahtBot requested a review from theStack April 18, 2025 12:01

theStack approved these changes Apr 19, 2025

View reviewed changes

rkrux approved these changes Apr 21, 2025

View reviewed changes

glozow merged commit 3e78ac6 into bitcoin:master Apr 21, 2025
19 checks passed

	bool can_keypool = parsed_descs.at(0)->IsSingleKey();
	// Only single key descriptors are allowed to be imported into a legacy wallet's keypool
	bool can_keypool = parsed_descs.at(0)->IsSingleKey();

		out.origins.emplace(keyid, std::make_pair(m_pubkey, info));
		out.pubkeys.emplace(keyid, m_pubkey);

descriptor: Move filling of keys from DescriptorImpl::MakeScripts to PubkeyProvider::GetPubKey #31243

descriptor: Move filling of keys from DescriptorImpl::MakeScripts to PubkeyProvider::GetPubKey #31243

Uh oh!

Conversation

achow101 commented Nov 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Nov 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage & Benchmarks

Reviews

Conflicts

Uh oh!

theStack left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

theStack left a comment

Choose a reason for hiding this comment

Uh oh!

fjahr left a comment

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!

Sjors left a comment

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!

rkrux Mar 6, 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!

Choose a reason for hiding this comment

Uh oh!

fjahr left a comment • 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!

fjahr Feb 1, 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!

achow101 Feb 10, 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!

fjahr Mar 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!

Choose a reason for hiding this comment

Uh oh!

theStack left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

fjahr commented Mar 5, 2025

descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` #31243

descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` #31243

achow101 commented Nov 7, 2024 •

edited

Loading

DrahtBot commented Nov 7, 2024 •

edited

Loading

rkrux Mar 6, 2025 •

edited

Loading

fjahr left a comment •

edited

Loading

fjahr Feb 1, 2025 •

edited

Loading

achow101 Feb 10, 2025 •

edited

Loading

fjahr Mar 5, 2025 •

edited

Loading

rkrux Mar 6, 2025 •

edited

Loading

rkrux left a comment •

edited

Loading

rkrux Mar 8, 2025 •

edited

Loading

rkrux Apr 16, 2025 •

edited

Loading

rkrux Mar 10, 2025 •

edited

Loading

rkrux left a comment •

edited

Loading