4
1
I understand how ECDSA exactly works and for verification of a signature, the public key of the signer is required. But in Bitcoin, public key is double hashed and the only information the receiver knows is the sender's address.
Then my question is that how the receiver can verify the senders signature without knowing his public key?
8
Simple, the sender shows the pubkey when spending from whatever address the bitcoins are in. As part of the verification, the receiver (actually, every node in the network), can verify that the pubkey hashes to the address given and then and only then verifies the signature.
2
static bool verify ( const QByteArray& dgst, const QByteArray& pub, const QByteArray& sig )
{
return 0 < ECDSA_verify ( 0, (const quint8*)dgst.constData ( ), 32,
(const quint8*)sig.constData ( ), sig.size ( ), EC_KEY_pub_key ( pub ) );
}
But what if the address has never made a transaction and thus the public key is not revealed? Is it impossible to verify it then? – Arturo Torres Sánchez – 2015-02-22T21:20:38.143
3If the address has never made a transaction, what is the receiver actually receiving? In that case, there isn't anything transferred between the parties (at least on the blockchain) and there's no need to verify anything. – Jimmy Song – 2015-02-22T21:22:11.507
@jimmysong Then what about the receiver. Receiver doesnt need to provide his public key until he wants to spend the money. Am I right? – abeikverdi – 2015-02-23T02:42:58.173
2Yes, addresses generally shouldn't be exposing their public keys until they're ready to spend. This is a good way to protect against ECDSA being broken in some way. Right now, an attacker would have to break SHA256, RIPEMD160 and the SECP256K1 curve to break that security. – Jimmy Song – 2015-02-23T03:17:07.100