Enable `importprivkey`, `addmultisigaddress` in descriptor wallets about bitcoin HOT 4 OPEN

I think importaddress and addmultisigaddress intents are clear enough and they map well to descriptors. Both specify the address type. Forcing users to learn how to craft a descriptor when they merely want to watch an address seems overwhelming to me. -> #27034 maps importaddress to addr() and raw() descriptors. And #28307 fixes and extends createmultisig/addmultisigaddress.

Not sure about importprivkey as it would clash with the new void(KEY) descriptor (#29136). The intent there isn't clear enough to me. Perhaps we could create a importkey or importwalletkey command where the user can input any type of key and specify its intent in one of the command arguments. Personally, I think the combo() descriptor should be more of a last-resort fallback that requires a warning, rather than the user's first choice, as it does not support newer output types.

from bitcoin.

addmultisigaddress might be a little bit more complicated since users would expect it to behave the same way and be able to have the specific private keys from addresses. Given that we do not want to allow exposing child private keys, retaining that behavior would allow extracting specific child private keys in a rather roundabout way (addmultisigaddress which puts creates a descriptor with a child privkey, then listdescriptors true which outputs the descriptor with that privkey).

Also both addmultisigaddress and createmultisig should allow xpubs and xprvs, currently only single keys are allowed.

I'm not sure that allowing importmulti is that useful. All of the stuff that you can do with it can be done with importdescriptors, and extremely similarly as importdescriptors' interface was based off of importmulti. In fact, if importing a descriptor with importmulti, the same argument can be used with importdescriptors. I suppose someone could be used to importmulti with importing all of the other stuff that it allows, but it's quite a mess and doesn't seem like it's used that much? I have seem requests for importprivkey, importaddress, and importwallet for descriptor wallets, but never for importmulti for things that importdescriptors can't do.

Not sure about importprivkey as it would clash with the new void(KEY) descriptor (#29136).

I think the distinction is clear enough given importprivkey's historical behavior, and that void(KEY) and addhdkey would be new. Namely, the expectation is that importprivkey imports a private key which produces all of the scripts produced by combo(). void(KEY) and addhdkey explicitly are adding a key that can sign but cannot produce any scripts.

from bitcoin.

@achow101 Hmm, what would happen if addmultisigaddress for descriptor wallets just imports the computed descriptor as it does now (with RPC arguments that must be existing addresses or hex pubkeys)? Would it support (participating in) signing for the resulting multisig address (assuming signing for one of specified addresses/pubkeys was possible prior to the RPC call)? Would listdescriptors true reveal the corresponding private key?

Agreed about importmulti. It's nontrivial to map to descriptors, and probably does not have much demand.

from bitcoin.

I think the issue remains that the rescan argument is boolean and optional in importaddress, which IIRC was one of the reasons to move toward importdescriptors. Yes, the importdescriptors interface is non-trivial, but I don't see how the burden can be taken off the user to think about the rescan timestamp of the descriptor. It needs to be accurate, because if it is too late, funds/txs may be missed, if it is too early, hours/days may be spent on a rescan.

If this is done, I'd say that importaddress should come with a breaking change for descriptor wallets to adjust the rescan argument to be identical in behavior to the one of importdescriptors.

from bitcoin.