BIP 388 wallet policies were introduced by @bigspider to make it easier to verify descriptors on a signing device.
A first step towards supporting them could be to add a policy and keys field to the getdescriptorinfo and listdescriptors RPC results. Only for the subset of descriptors that BIP388 allows.
These fields can be manually passed into HWI using this (somewhat old) PR https://github.com/bitcoin-core/HWI/pull/647 as well as through other (?) tools.
policy and keys fields to the getdescriptorinfo and listdescriptors RPCs for BIP 388 wallet policies. I’ll be diving into the BIP and the existing code in the next few days, and definitely checking out that older HWI PR for insights.
One caveat is that a wallet policy typically uses /** to indicate a combined receive and change descriptor <0;1>. Although we can import such combined descriptors, we store them seperately and forget about the unified original. So the listdescriptors command would return a useless policy value.
We could make listdescriptors smart, but it’s perhaps better if don’t give it a policy and keys field and instead introduce a new listwalletpolicies RPC that is smart (and only considers the subset of descriptors that comply with BIP388).
I therefore think (only) getdescriptorinfo is the easiest place to start.
Thanks for the clarification! That’s a crucial point about listdescriptors and the /** handling.
I agree completely that getdescriptorinfo is the right place to start. My plan is to focus on implementing the policy and keys fields there, by adding logic to parse the input descriptor into a BIP 388 policy if it’s compatible.
I’ll keep the idea of a dedicated listwalletpolicies RPC in mind for a follow-up contribution, as that seems like the cleanest way to expose stored wallet policies without forcing listdescriptors into an awkward reconstruction.
Labels
Wallet
RPC/REST/ZMQ