Verify Message provides the address #1356

The JSON-RPC verifymessage intentionally required the user to provide the expected address, and returned success or failure, to avoid potential social engineering: if the user is simply told the signing address, someone could use vanitygen to create a similar-looking address and attempt to fool the verifier when they compare it. The recently merged Verify Message dialog introduces this attack vector.

I propose making the Address field editable, and having the Verify button simply display "Signature valid" or invalid in a messagebox.

In the RPC I think the requirement to specify the address is a nuisance — esp in cases where there simply wouldn't be an opportunity to social engineer— e.g. where the address is itself the relevant 'account'... and I wouldn't be sad to see that feature go. In the GUI OTOH I tend to agree.

Perhaps make the verify box an input field, and if it's correct it instead tells you what the address should have been in the sorry you lose box? This way use case that don't need to know the address in advance can still get it, but users are still encouraged to let the machine do the comparison.

@gmaxwell To understand the feature as it's intended, I need to supply a signature and a message and won't get the address out of the two. I just can verify, that the person, who send me both seems to be the owner of the signing address (I don't know or don't need to know).

I did some further tests and it seems the verifymessagepage is badly broken!

• create a signature from a testnet-address
• start normal net client
• paste signature and message -> no error, displays a bitcoin address (but not the one used to sign the message)
• paste only signature -> no error, displays another bitcoin address (still not the one used to sign the message)

If I repeat this via RPC Console on normal net, the verifymessage is not accepted without the signing address and even if I supply the testnet address, I get "code":-3,"message":"Invalid address". On the testnet client the verification works!

I'm going to change the verifymessage page, to match the RPC command verifymessage

@Diapolo that's quite expected - the signature does not encode whether it's from testnet or not. The key recovery mechanism (which does require the message, by the way) can recover the public key, but the address that corresponds to it depends on which network you're on.

@sipa: Alright, even if the behaviour is expected, I think the verifymessage page should act like the RPC verifymessage. It does not make any sense to "recover" an address (or key) that was not used to sign the message. As I wrote, the current state allows to use a valid signature, enter any message and get a Bitcoin address displayed. I have code ready, that changes it to behave like verifymessage.

@Diapolo both the testnet address you signed with and the bitcoin address you got are the same key; you can export it from testnet and import it to mainnet to use it there. Pasting the signature without the message is obviously a bug for sure, though, and I do believe the behaviour should be corrected here.

This can be closed, as even without the tabbed UI, the current verify dialog matched the RPC-call behaviour.

Confirmed