Ok, so there is nothing much to add to what theymos said...
Except, that on most "digital signatures" the full certificate including the public key is included in the signature block. Otherwise they are hard to validate because there is nothing to map the seemingly random signature part to any particular person's public key.
Since bitcoin doesn't use certificates, (I think) they add the signature and public key as a separate fields in the transaction.
Topic: Verification of transactions (Read 7678 times)
You usually send bitcoins to a hash of a public key (the Bitcoin address). When the receiver spends those coins, they include their full public key. To verify, you check to see if the hash of the full public key is equal to the hash that the bitcoins were sent to.
It's also possible to send bitcoins to the full public key from the start. This is done in transfers to IP addresses and transfers to yourself.
It's also possible to send bitcoins to the full public key from the start. This is done in transfers to IP addresses and transfers to yourself.
I've been doing some more research, and I suspect the above is probably not 100% correct.
There does seem to be a difference between the actual public key and its hash, and where each is used.
What I am sure of:
Transaction signing is done using Elliptical Curve Cryptography.
The Bitcoin Address contains enough information to verify that the transaction has been signed correctly.
There does seem to be a difference between the actual public key and its hash, and where each is used.
What I am sure of:
Transaction signing is done using Elliptical Curve Cryptography.
The Bitcoin Address contains enough information to verify that the transaction has been signed correctly.
Not sure how far from 'lay' this is straying..
The public key is a 160 bit number.
The Bitcoin Address *is* the public key. (+ version + checksum + encoding, which all get stripped off when you just need the key.)
Transaction signing is done using Elliptical Curve Cryptography.
The public key is a 160 bit number.
The Bitcoin Address *is* the public key. (+ version + checksum + encoding, which all get stripped off when you just need the key.)
Transaction signing is done using Elliptical Curve Cryptography.
Okay, thanks.
Not sure how far from 'lay' this is straying..
The public key is a 160 bit number.
The Bitcoin Address *is* the public key. (+ version + checksum + encoding, which all get stripped off when you just need the key.)
Transaction signing is done using Elliptical Curve Cryptography.
The public key is a 160 bit number.
The Bitcoin Address *is* the public key. (+ version + checksum + encoding, which all get stripped off when you just need the key.)
Transaction signing is done using Elliptical Curve Cryptography.
Are you saying that the public key *is* the address? My prior understanding was that the address was a hash of the public key.
Does it matter?
Yes, it does.
What I'm actually asking is this...
What prevents a hacked client from submitting a transaction that falsely claims an existing address with a balance, and signs it with any private key? How do the clients verify that the signature and the address actually belong together? If the address is the private key, I can understand how this is easily verified; since that is the point of public key encryption. However, if the address is a hash of the public key, and not the public key itself, how do the clients aquire the public key in order to check the signature? How do they check the hash that is the address against that public key to verify that they go together?
Are you saying that the public key *is* the address? My prior understanding was that the address was a hash of the public key.
Does it matter?
The public key/Address is made public when it gets coins put into it.
Are you saying that the public key *is* the address? My prior understanding was that the address was a hash of the public key.
The public key/Address is made public when it gets coins put into it.
Either by:
a) Coins "falling out of the sky" as a block generation reward.
or
b) it appearing as an output (TxOut) of a previous transaction.
So when you want to check a transaction. You make sure:
a) The Address has the right amount of coins in it. (Because you've seen it before as a TxOut.)
b) The transaction has been signed with the private key. (So you know it's the owner spending it.)
Edit: Added transaction checking info
Either by:
a) Coins "falling out of the sky" as a block generation reward.
or
b) it appearing as an output (TxOut) of a previous transaction.
So when you want to check a transaction. You make sure:
a) The Address has the right amount of coins in it. (Because you've seen it before as a TxOut.)
b) The transaction has been signed with the private key. (So you know it's the owner spending it.)
Edit: Added transaction checking info
Can someone please explain to me, in lay terms, how a client can verify that a given transaction is an honest one? The address is a hash of a public key, and the transaction must be signed with the matching private key; but how does a client check that the signed transaction actually matches the sender's address without the public key? Or are the public keys made public at some point in the chain?
Jump to: