Added extractpubkey rpc call, allows extraction of public key from a message and signature. #3473

Can be useful for logging into websites, without requiring the user to enter a username when they log in. User signs a message and the site recovers the public key from the known message and signature and checks the public key belongs to a user in the database.

No opinion on including this, but if its done can it have another name? I expected this to be another duplicate of validateaddress' function in returning the public key.

I was thinking this too, it doesn't really emphasize in the name that it's for recovering a key from a message and signature, like signmessage and verifymessage do. Something like getpubkeyfromsignature might be more appropriate. I'm open to recommendations regarding the name.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/0d669ae5737201aeae61bf1389040dac5944e7a8 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

Why not just return an additional value from validatemessage, instead of adding an additional rpc?

Because validatemessage takes in the expected address, in his application you don't know it.

(And it's important that it takes in the expected address, because apparently the fact that every signature can return a public key has caused some people to get validation wrong— taking in the expected address allows it to give a true/false)

This could be included into verifymessage for when the address field is left blank and then verifymessage would return the recovered public key, or the 'recovered address', but that adds some complexity to the call and the code inside it.

The possible address space is 2^160, this just allows people to check the pubkeyhash/address themselves, it's very useful for some things that I'm building for user verification. So I figured I may as well add it back into the repo.

Right. It's indeed slightly different.

This kind of operation doesn't really need any of bitcoind. Not the blockchain, not the P2P network, not the wallet. It would be better to have it an external bitcoin ecdsa library instead of an RPC call.

@laanwj

That's true, but the same can be said for signmessage, verifymessage, validateaddress and signrawtransaction etc, most bitcoin services / websites use bitcoind rpc for everything as its the easiest way to interface with the bitcoin keys/addresses without having to trust external libraries which limited people have checked.

This is useful to me and might probably be useful to others in the future, but external ecdsa library might be a better way to go for many of these functions.

This seems kind of worthless, tbh. If you want people to log in to websites using ECDSA keys, use SSL client certs. It's already supported out of the box by all mainstream software.

The problem is, nobody is using SSL client certs, they're difficult to use, in most browsers you have to go into advanced settings to see them and then they're locked into the browser, which can make it difficult to manage when using multiple devices. I agree it's only a minor change from verifymessage, but this is very useful for a server wanting to validate a user without having to ask the user for an address/signature combo every time.

They tend to be stored in the operating system keychain rather than the browser, but yes, I agree they are not that easy to use. However your proposed alternative would have even worse usability. If you want to help people log in to websites more securely, improving web browsers and making it easier to configure servers would be a good idea. Some suggestions are here:

http://eprint.iacr.org/2013/538.pdf

Ability to extract a pubkey from a signature is not harmful or anything like that, but you could easily do it with a bit of custom code too, so it's not really clear this is a particularly useful RPC. Do you have any use cases for it which are NOT web site logins?

Not really any other uses that I want to use, I'm sure there could be some. I just thought I'd publish this to see if there was any interest.

+1 I could think of a few use cases. Imagine you have some message, e.g. the sha256 of a file and you want to know who has this particular file.

When validatemessage was designed, it was an intentional decision to NOT make this possible...

While I don't have a use for this specific RPC, I will point out that it would be darned useful to have a multisig-friendly way to either (a) get a fresh pubkey or (b) get a pubkey, given an address.

IIRC validateaddress returns the public key given an address.

Reminder: This extracts the public key from a signature and signed message.

Closing this. I do not deny that this new command can be useful in some edge cases, but it is too specialized and specific to make it worth the trouble to maintain it within bitcoind. A said I suggest building this as a separate library (should not be difficult to implement this using python-bitcoinlib for example)

@tarbell I've got a project called Tarbell that I would very much like to create an organization for on Github. Since you seem to be inactive (so much so that I can't even check out a repository to find your email address), is there any way you'd consider releasing the username? You can reach me directly at heatherjaybillings at gmail. Thanks, and sorry for spamming an old pull request thread!

Sorry for bringing up such an old issue - but I've run into a situation probably very similar to @tarbell here. It would be very handy to allow verifying messages without the need to specify an address explicitly. @gmaxwell said in an even older issue that it would be handy to allow verifymessage to work optionally without an explicit address.

What is the current take on this? I understand that having a separate extractpubkey RPC call is mostly a maintenance burden as stated by @laanwj above. But what about modifying verifymessage in a way that allows it to return the address? For instance, if an empty address is passed, it could return a JSON object like this:

{
  "valid": True,
  "address": <address>
}

instead of just a boolean. Doing so would be very simple (just a few lines of code) and thus not have much of a maintenance burden at all. I can do that specifically for my own application, but I wonder if it would make sense to implement this in Bitcoin Core directly (so others can make use of it as well).

@domob1812 What's the use case?

@luke-jr: I have a system where users can designate one or more addresses to be allowed to sign certain messages on their behalf (i.e. as their public keys).

Now when I validate if a message was signed by some user, it is much more efficient to get a "prospective address" from verifymessage and then verify if that address was designated by the user, rather than calling verifymessage for all designated addresses to see if any returns true.