wallet: listdescriptors uses normalized descriptor form #21277

Rationale: show importable descriptors with listdescriptors RPC

It uses #19136 to derive xpub at the last hardened step.

Before:

[
    {
      "desc": "wpkh(tpubD6NzVbkrYhZ4YUQRJL49TWw1VR5v3QKUNYaGGMUfJUm19x5ZqQ2hEiPiYbAQvD2nHoPGQGPg3snLPM8sjmYpvx7XQhkmyfk8xhsUwKbXzyh/84'/1'/0'/0/*)#p4cn3erf",
      "timestamp": 1613982591,
      "active": true,
      "internal": false,
      "range": [
        0,
        999
      ],
      "next": 0
    },
    ...
]

After:

[
  {
    "desc": "wpkh([d4ade89c/84'/1'/0']tpubDDUEYcVXy6Vh5meHvcXN3sAr4k3fWwLZGpAHbkAHL8EnkDxp4d99CjNhJHfM2fUJicANvAKnCZS6XaVAgwAeKYc1KesGCN5qbQ25qQHrRxM/0/*)#8wq8rcft",
    "timestamp": 1613982591,
    "active": true,
    "internal": false,
    "range": [
      0,
      999
    ],
    "next": 0
  },
  ...
]

cc @achow101 @laanwj

Concept ACK! Thank you.

What does it currently return here? Before/after would be nice. Maybe it's ToString that needs to get revised?

Would be nice to avoid needing the wallet unlocked to simply listdescriptors...

What does it currently return here? Before/after would be nice. Maybe it's ToString that needs to get revised?

Updated description to show before/after. ToString() is fine, it's just ToNormalizedString() is better in this case.

Would be nice to avoid needing the wallet unlocked to simply listdescriptors...

In general I agree, but to derive normalised descriptors for hardened derivations we need private keys.

UPD: Apparently, I didn't save the updated description at time of posting. Fixed now

I'd agree that needing to have the wallet unlocked is a drawback.

But the thing is that the current output is not really useful for anything (I think). You could say it's not even a valid descriptor as it does a hardened dirivation from a xpub.

E.g. like

    "desc": "sh(wpkh(tpubD6NzVbkrYhZ4Yj6Abshu22tUGYKVK6xcazXuGmxRkLTqrMfpc6u7Bpr31wmqe8kJc7Y5ZCvKdvVRtsZhfB5hdLpUndFFc5mXat72euorqFE/49'/1'/0'/1/*))#g7vg94cx",

In general I agree, but to derive normalised descriptors for hardened derivations we need private keys.

Hmm. It might be an idea to store these at generation time.

Hmm. It might be an idea to store these at generation time.

It's totally doable, but doesn't it violate users security assumptions? If I have my master private key encrypted at rest I would be unpleasantly surprised to find child private keys in memory.

If I have my master private key encrypted at rest I would be unpleasantly surprised to find child private keys in memory.

I mean the public key, not the private key. This is all about public derivation right? I'm certainly not suggesting private keys should be stored unencrypted.

The xpub cache should actually allow us to generate the normalized form without needing to unlock the wallet. After all, that is how we are able to refresh the address pool when the wallet is locked. However modifying the normalization function to do that may be an invasive change. I can look into doing that. Regardless, doing that would not materially effect this PR and I think it can be done in a followup.

ACK a69c3b35f8974b378a87a3e42d331bd4147e07df