Code wise, this is more of a refactor (much more lines are touch for refactoring then the intended feature).

Wouldn't' the non verbose mode (== directly return hex) include some risks because one my miss important errors (sent back through the "error" json array/object)?

@jonasschnelli For fundrawtransaction, you will no longer see the resulting fee, which is a pity, but if you don't need to know it, it's fine. For signrawtransaction, you will not see if it was only partially signed, which may trip you in certain cases, but I don't think it would end up in lost money or be dangerous (you just have a transaction that the network will reject).

@kallewoof your right about fundrawtransaction (I mixed it up with bumpfee). But what about signrawtransaction Errors like TxInErrorToJSON(txin, vErrors, "Input not found or already spent"); or the possible script sig errors?

I think its probably acceptable to suppress those errors, but maybe we should mention that in the help description.

I'm actually confused why the sign code doesn't throw an error in the case you mentioned. Why would it continue when the tx appears to be broken? Hm..

Does this sounds more like a bash mode for cli than verbose option?

Edit: Do we want this option in the RPC interface?

Another suggestion to ease chaining and eventually reduce the transmitted data is to specify a json path to filter the output. For instance:

bitcoin-cli -rpcfilter '*.amount' listunspent

Compared to jq, it has the advantage of server side filtering. But I guess it is too much for core.

Does this sounds more like a bash mode for cli than verbose option?

I chose verbose because if you look at e.g. createrawtransaction it responds with the hex only (the same style), whereas the ones here will respond with a JSON object with extra information. That to me was actually a bit unexpected, and it still trips me up on occasion when I'm trying to do something (I somehow think the results will be the tx hex when in fact they're a json object).

IMO verbose is unclear and usually means more detailed logs which is unrelated.

Also, I think we should discourage chaining these calls because the middle results/errors are important and should be acknowledge/logged/handled/whatever.

As you said, it's still doable using other tools.

Not sure about others, but for me it's a NACK.

Verbose is not restricted to logs, in my world. The word itself simply means "using or expressed in more words than are needed" which I think fits very nicely with the use case here (you don't need the complete flag for signing, for instance; it's just a helpful thing to have).

Yes, it's doable using other tools, but this dependency is rather superfluous considering the relatively small addition (style fixes outweighs the code itself) means less work for the node (a string rather than a JSON object).

It's ultimately ~2-3 lines per RPC call to remove a potential dependency on external tools. I think that's worth something personally.

Concept ACK. I think chaining commands together without intermediate error checking like this is definitely dangerous and poor practice, but there are probably legitimate use-cases for testing, etc.

Thinking out loud: verbosity is a very common option for RPCs. Perhaps we should consider making it a query string in the URL rather than adding parameters to every RPC that requires it. Maybe that's not practical, but worth considering.

Rebased, and dropped signrawtransaction patch and added signrawtransactionwith* support instead.

One NACK, one concept ACK. I think it's not worth keeping this around.