We should educate users that the number of coinbase utxos selected for shielding is limited by
both the -mempooltxinputlimit=xxx option and a consensus rule defining a maximum transaction size of 100000 bytes. We could recommend a value for -mempooltxinputlimit in a blog post so that users avoid the issue where some miners choose not to mine transactions with a large number of utxo inputs, resulting in the transaction languishing in the mempool. #2668

See also user who filed ticket "2-day delay in mining a transaction with 586 transparent inputs" #2668

I think we should add a parameter to the RPC, with no default, for the maximum number of inputs to be used.

Yes, I think we should add a mandatory parameter for this, before the optional fee parameter.

How on Earth are users supposed to guess a suitable value for this parameter?

@tromer Yes, I agree with that sentiment too. Trying to think how we can avoid issues like #2668. It might be simpler to explicitly state in the help message for the command that for the time being, if they have lots of coinbase utxos, they should restart their node with -mempooltxinputlimit of 50 or 100.

@daira Regarding quadratic hashing fix, see #2584

@str4d Thoughts? Overall I'm leaning towards updating the help message.

Users will inevitably ignore the help message, and it will appear to work as long as they have few coinbase utxos. Later on, when they end up with many coinbase utxos, they'll run into #2668 and won't know why.

The default must follow the principle of least astonishment.

Yes, having a magic-number default is inelegant, and creates a minor technical debt; but externalizing it to users isn't a good tradeoff.

Apropos the help message, it's doesn't explicitly say what happens if there are no coinbase utxos to shield. Does it still return an operationid, even though no txn is generated (similarly to z_sendmany with inadequate balance, for example)? Or an error?

Also: if changing the RPC interface is still in the cards (despite the experimental-feature deployment), then I advocate for renaming this RPC call to z_shield, with an argument saying whether to shield all utxos, just coinbase or just non-coinbase.
(cf. #1785, and chat starting https://chat.zcashcommunity.com/channel/zcash-dev?msg=932K3NKgedjbsg9KX).

If there are no coinbase utxos to shield, an error is returned to the user.

Principle of least astonishment... yes... an optional parameter with a default of 50 would work well. I quite like this idea.

There are more parameters for z_shield which we haven't decided/discussed yet e.g. "amount", "zchangeaddress" so it's a bit early to lock down the interface to z_shield and tie it to z_shieldcoinbase which performs a subset of functionality.

@tromer @str4d @daira I will add an optional parameter with a default of 50 as when discussing testing with some folk, one of the first things they asked for was to limit the utxos to 1, in case something went wrong, but restarting the node and setting the -mempooltxinputlimit limit was too much hassle at the time and they didn't want any downtime.