optionally provide privkey to signmessage RPC #7899

Add an optional 3rd parameter to signmessage to allow the user to specify the private key to use for signing the message.

Commit message too long.

Concept ACK.

Why require an address? What's the temporary keystore for?

It always required an address. I guess it could accept a private key in place of the address - is that what you're getting at?

The temporary keystore is for holding the supplied private key, much like the one in rpc/rawtransaction.cpp's signrawtransaction code.

This seems like a useful function to have, but I prefer having separate functions for wallet-dependent rpcs and utility rpcs that get fed all their arguments.

Also, would it suffice to add this to bitcoin-tx instead?

So would you prefer a new RPC, signmessagewithprivkey or similar, and have the existing signmessage left as it is?

This it the first I have heard of bitcoin-tx. A quick look at it suggests it is for creating and working with raw transactions, whereas this PR is about signing messages.

Having said that, I don't mind where it is added. I just want a way of signing a message with a private key not in my wallet that doesn't require me to shut down bitcoind, move the wallet.dat out of the way, restart it, import the private key into a new wallet, sign the message, shut down bitcoind again, delete the temporary wallet, move the original wallet back and restart bitcoind again. Because that's kind of long-winded.

And what about new utility bitcoin-msg?

Agree with @sipa. Signing a message with a provided private-key is pure utility. The only dependencies you need are libsecp256k1, some entropy source and sh256. Not sure where it would fit best (bitcoin-msg sounds good but maybe there is something more generic).

Signing does not need an entropy source.

@sipa: how would you then randomize the context (like secp256k1_context_randomize()) https://github.com/bitcoin/secp256k1/blob/master/include/secp256k1.h#L558 ?

Concept ACK, however: please add a new method to sign message without wallet (thus providing the key), don't add another optional-wallet RPC call, or optional argument to signmessage. One near-future goal is to get rid of #ifdef ENABLE_WALLETs, to prevent circular dependencies and make the wallet a better isolated unit. @jonasschnelli

@sipa: how would you then randomize the context (like secp256k1_context_randomize()) https://github.com/bitcoin/secp256k1/blob/master/include/secp256k1.h#L558 ?

Signing is deterministic as of #5227, so there is no randomness needed for signing. If there is some implementation problem with secp256k1 that (due to context dependencies) requires it that should probably be solved there.

A separate bitcoin-msg seems a bit excessive.

A separate bitcoin-msg seems a bit excessive.

Agreed. Mind that we're using (pseudo-)static linking, so every new executable adds a hefty size to the archives. Let's just add a wallet-independent RPC call for signing messages. verifymessage in rpcmisc.cpp doesn't depend on the wallet either, so you could add it below that.

So, to summarize, the current approach is not mergable as it doesn't change the dependency on the wallet.

Good options would be:

• Adding message signing/verification functionality to bitcoin-tx
• Adding a new RPC signmessagewithprivkey or similar (non-dependent on the wallet)

Bad options are:

• A separate bitcoin-msg utility. This is overkill. @dooglus Are you going to move this forward, or would it be better to close and wait for someone else to pick it up?

Closing in favor of #7953