User Verification – Addresses

Now, let’s go one step further. Instead of saying, “Bob can spend this coin”, Alice uses Bob’s public key to address him. Actually, she says: The person owning the secret key corresponding to a certain (Bob’s) public key is allowed to spend this coin.

Since using pure public keys is a bit inconvenient, they are further processed to addresses. This brings us the advantage of adding a checksum to prevent typos and gives us an extra layer of security in case the elliptic curve got broken at some point in time. But it doesn’t change the process described above.

A Bitcoin address looks simply like that: 18Zcyxqna6h7Z7bRjhKvGpr8HSfieQWXqj. You can think of an address as an IBAN and your private key as your PIN.

If Bob wants to send the coin he had received from Alice further to Chris, he now has to ask Chris to tell him her address first. He then creates a new transaction pointing to the transaction from Alice, which is now his coin and says:

“The owner of the secret key (Chris’s secret key) corresponding to this address (Chris’s address) is allowed to spend this coin.” He proves that he is allowed to spend this coin by signing his transaction with his secret key.

So far, we have solved the identification issue by replacing names with addresses and secret keys. But we haven’t solved the double-spend problem yet.

Bob still could point to Alice’s transaction twice. First, by saying that Chris is allowed to spend this coin. and second, by saying Deborah is allowed to spend this coin.

This means the network somehow needs to figure out which transaction is actually the right one. This brings us to the topic consensus.