bitcoin-cli has no way to omit positional params, but when creating a watch-only wallet, createwallet will error if passphrase is provided. This effectively prevents such commands from using the later parameters (avoid_reuse, descriptors, load_on_startup, and external_signer).
(n.b. all of those inaccessible params should really be an options Object when using positional parameters anyway; why does the interface suck? :/ )
Actually, it looks like we accept the null string here. User reporting it has something else going on.
It's the error message we get. I'm not even sure the wallet is created.
$ bitcoin-cli createwallet MyWatchWallet true true null false true true
error code: -4
error message:
Passphrase provided but private keys are disabled. A passphrase is only used to encrypt private keys, so cannot be used for wallets with private keys disabled
Named parameters can be used.
bitcoin-cli -named createwallet wallet_name=MyWatchWallet disable_private_keys=true blank=true descriptors=true load_on_startup=true
I agree this should be changed to an object, but it needs to be done in a way that doesn't break the API for existing users.
(n.b. all of those inaccessible params should really be an options Object when using positional parameters anyway; why does the interface suck? :/ )
I think the reason the interface is awkward is that #19762 hasn't been merged, so there is no way to combine positional arguments with named arguments. #19762 is a basic building block that could be extended more, but this approach should be more command line friendly than using an options object, because you can pass the options as name=value literals, and not have to manually construct json object literals using braces and quotes and double-escaped strings. It is also more python-friendly because python naturally supports combining named arguments with positional arguments, so it removes an artificial error preventing this when calling RPC functions from python.
They shouldn't have positions in the first place. #19762 is fine, but it needs a non-standard JSON-RPC client.
The positional arguments should simply take an options Object at the end of the logically-positional params, like other existing RPC methods do.
#17356 would have been a good step toward making this simpler, but alas never got enough eyes.