scantxoutset does not identify UTXO origins #14503

This is related to #14150 and possibly others, but it's actually a separate issue.

For instance, when using the following query: bitcoin-cli scantxoutset start '[{"desc":"wpkh(xpubABCDEF/0/*)", "range":100}]' I can get a list of UTXOs, but no way to get back the index which derived that particular UTXO. So it's not much better than deriving on the user side and specifying addresses one by one, so that I already have a cache of addresses to match.

Not sure what the solution looks like. One way is to repeat the full descriptor in the utxo. That might get verbose though.

That's a great point.

With #14150 there is a way to include the fingerprint and path of listed public keys to descriptors.

Then it would be easy to make scantxoutset report a descriptor "specialized" to what matched (but without repeating the full xpub; it would just show pkh(ab1234cd/0'/0'/44'/0/13:03bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb) (where the sequence of b's is a hex pubkey).

Would that be more useful?

So in my example, I'd specify: "desc": "wpkh(ab1234cd:xpubABCDEF123456.../0/*) and get back something like: "desc": "wpkh(ab1234cd/0/17:03bbb...)" right?

That's a reasonable sounding solution. I don't see why the pubkey needs to be listed though. Is it to conform to the descriptor format? Or is there a usecase when you need it? (you should be able to derive it from the path information though)

For someone who has the master pubkey, yes. But descriptors are standalone. Without the pubkey in there you can't compute the address or redeemscript/witnessscript.

I'm confused now. I am talking about matching the resulting UTXOs in scantxoutset results to the appropriate query strings; when I'm submitting a query, I can do the same pubkey derivation that bitcoind would do on my behalf. (consider: what if I'm querying multiple addr() descriptors? in that case we can't get the public key. i could match addrs on scriptPubKey as it stands now, but if there's an additional field, it should contain something reasonable)

You seem to be talking about more specific case of returning stand-alone descriptors, possibly in other scenarios too?

@matejcik I suppose the answer is "to conform with the descriptor format", which are expected to be used for a number of other things (including importing into wallets, where you need to know what to watch for without access to the xpubs involved).