User Verification – Signatures, Private Keys, Public Keys, and Addresses
First, we have to make sure that only the right user grants the permission. So, for example, Bob should not be allowed to create a transaction for coins Alice owns.
In order to verify that Alice created a transaction, Alice needs to sign it with a digital signature. Digital signatures are a bit different from written signatures but have the same goal, secure a document or me. The first step of creating a digital signature is to create a secret key. So, Alice creates secretly her secret key and derives from it a public key. Sometimes the secret key is also-called a private key.
Creating a secret key is actually pretty easy. It is a very large random number (in Bitcoin 256 bit). You can do this by flipping a coin 256 times and every time the number occurs you write down a 1 and if the symbol occurs you write down a 0.
The derivation of the public key is a one-way process done with elliptic curves. We leave the math aside since this is really difficult to understand. But what is important is that it is impossible to retrieve the secret key from a public key! It is a one-way function.
Now having such a key pair Alice can create her signature.
With her secret key, she signs the transaction via Elliptic Curve Digital Signature Algorithm (ECDSA). Again, the math behind this is pretty daunting, that’s why we leave it aside again. The result is a signature which is a pair of two pretty large values r and s. Alice sends this signature along with her transaction and her public key to Bob.
Bob and all other nodes can verify if this signature is valid by checking it with the provided information by Alice.
A digital signature algorithm basically has three functions:
- Create key pair
- Create signature: sign(m, private key) = (r,s)
- Verify signature: verify(m, signature, public key)
The good thing is that Alice can sign many transactions with her private key but nobody will ever find out what the private key is.
Another feature of digital signatures is, that the signature is also different on every transaction because it depends on the content. This is a big advantage over written signatures which can be copied and pasted into another document. Whenever you change the transaction you want to sign, the signature is different.
In fact, every user of the blockchain network creates such a key pair (secret key and public key).
However, elliptic curve digital signatures have one downside. They cannot take input messages beyond a certain length. This problem is circumvented by calculating the hash of a message (in our case the transaction) and signing the hash.
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.
An address looks simply like that: 18Zcyxqna6h7Z7bRjhKvGpr8HSfieQWXqj. You can think of an address as an IBAN and your private key as your PIN.
There are different kinds of addresses that state what kind of transaction can be sent to this address. In the beginning, it is not important to know about those different addresses. But for the sake of completeness here is a short overview.
| Type | Explanation | Example Address |
| P2PKH | Starts with 1 | 18cBEMRxXHqzWWCxZNtU91F5sbUNKhL5PX |
| P2SH | Starts with 3 | 3P4URbP5DxTwBgEd57X6HFu9W6f2nFnFp6 |
| Bech32 | starts with bc1 | bc1qqxltnu2hha0mvuzufu9pn4e9s5py28z3nmkzl8 |
