Bitcoin uses a very similar process of public key cryptography. Instead of signing messages, however, the bitcoin program allows you sign to transactions.
How are Bitcoin transactions signed?
So now that you have gotten an understanding of how PGP encryption works, you can start thinking of Bitcoin signatures. It’s a little tricky however. The naive thinking would be to expect that when you create a transaction offering to deduct X amount of bitcoins from your account and transferring them to Y, you would simply sign this proposal. But that has a problem. If you are just creating transactions stating that you want to transfer your assets, then who verifies that you do indeed have the money? It would require some central authority for verification. That’s not how Bitcoin is designed to work. The power ultimately rests in the hands of the users. Bitcoin proposes a nifty solution. Here’s the idea: it is only possible for you to have bitcoins if you received bitcoins at some point in the past. Hmm… aha! Make public key serve the role of identity. This way the only person who can claim the transaction, is the one who holds the private key. And so, Bitcoin signatures serve two-fold purpose:
- It verifies that you are the true creator of the transaction, and
- you do indeed own the Bitcoins that you are about to transfer.
The latter is fundamental. We will see in some other post how this forms the basis for wallets (or collection of accounts). By the way, Ethereum works slightly differently in a way that it does introduce a standalone concept of accounts³. But Bitcoin is simply a chain of transactions. And so, for ownership, you have to scan the chain of transactions and to spend them, you have to unlock them and use them in a transaction.
Side Note: You might be wondering: Ethereum has a better design because it allows for creation of accounts. It really depends on the use-case. Simplicity in design is what allows the system to remain streamlined and Bitcoin does achieve its purpose of being a store of value. Ethereum, on the other hand, enables more use-cases but at the cost of being less streamlined and more bulky.
Each transaction is composed of inputs and outputs. Each input comprises of some previous transaction. And each output comprises of the destination where the funds are being sent. When you sign a transaction, you sign both inputs and outputs. By the signing the inputs, you are effectively saying that you are the true owner of those coins. And by the signing the outputs, you are agreeing that you do indeed want to send those coins to the specified address. To keep the money flow going, each output of a transaction is used as input to another transaction.
Enough theory. Let’s see a real transaction.
Heh, that’s the actual transaction that is transmitted over the wires. There is no way we can understand anything from it. How do we interpret it? One word: Protocol.
A protocol is a standard used to define a method of exchanging data over a computer network
If we look at the transaction protocol rules⁴, we can see how the transaction was constructed.
Let’s break down the transaction according to the protocol.
Contains metadata information. For instance, it tells the program that this is a transaction message.
Allows for backward compatibility. If the protocol is updated with a new field, old transaction shouldn’t become unrecognizable.
This is a field that was introduced as part of segregated witness change⁵. We will look at it some other time.
Transactions contain only the references to a particular output of a previous transaction that is being spent. It uses a combination of a transaction hash and the output index number (starting from 0). The idea here is that it’s simpler to just reference a previous transaction. If needed, the program can fetch the full transaction using its hash. And using the index number, it knows which output is to used as an input.
To calculate the transaction hash, you concatenate the full HEX representation of the transaction and compute the SHA256 of that string twice⁶.
Outdated. See https://bitcoin.stackexchange.com/a/55113.
Amount (in satoshi) that is being sent.
The block number or timestamp at which this transaction is unlocked.
Public key script (scriptPubKey)
The destination of the transaction. Hidden in this script is the public key hash of the receiver represented as a hexadecimal. To get the corresponding Bitcoin address, simply convert this HEX to Base58.
Signature script (scriptSig)
Similar to the scriptPubKey, scriptSig contains the signature that authorizes the transaction. Every part except the signature itself is signed.