Blockchain & Cryptocurrency #12: Bitcoin Transactions Schema

In this course section, we will go into further details talking about Bitcoin transactions and looking at real data structures and real scripts.

Bitcoin transactions

At the moment, to simplify the model, we will suppose that single transactions are added to blocks and not a set.

Account based system problems

So, now we could think about an account based model in which there are creation transactions that release new Bitcoins and later transactions to transfer the Bitcoin between users. For example Alice could have 25 Bitcoin from a creation transaction and transfer 17 to Bob. So, at the end, Alice should have 7 Bitcoins left. And so on.

The amount of Bitcoin contained in Alice and Bob account will continue to change as they transfer and get money from other users. In this kind of system in which the transaction are inserted one by one in the blockchain, it is still necessary to remember the amount of money available in each account to check transactions validity. With this kind of system it will be necessary to look at all the transactions since the beginning to know the balance. It's very complicated, so this model would need an additional structure to remember user current balance.

Ledger to keep track of transactions

That's why Bitcoin isn't based on an account based model like the previous one. Instead Bitcoin uses a ledger that just keeps track of transactions. So how does that work? Let's see a transaction based ledger, which is very close to Bitcoin.

In this model the transactions explicitly specify a number of inputs and a number of outputs (two arrays). In addition, each transaction has a unique identifier. So, let's see how it would work with this model:

1. the first transaction has no input, because it corresponds to new currency being created. It has an output of 25 Bitcoins going to Alice. It's a creation transaction, so no signature is needed. It's identified uniquely by Id 1.
2. then Alice wants to send some money to Bob. She refers explicitly to the transaction 1 where these coins comes from. So the input of this transaction will be the output index 0 of the first transaction. Then this transaction has two outputs: 17 Bitcoin going to Bob, 8 Bitcoin going back to Alice. The idea is to fully consume the output of the previous transaction, sending the exceeding money back to herself, this operation is called change address.
3. then Bob does transaction 3 towards Carol and himself referring to the output index 0 of transaction 2. And Alice tries to make transaction 4 using the money of transaction 2 index 1.

Check transaction validity

In this case it's easier to check the validity of last transaction: it is enough to check transaction 2, output 1, and verify that there's enough money there and that this money wasn't used already. Now it enough to follow just one hash pointer to a previous transaction to figure out whether or not there is enough money to cover the desired outputs in the new transaction.

Conceptually one could think that maybe this isn't much different than just maintaining a separate data structure which tracks account values for each person. The nice thing is that now this data structure is embedded within the blockchain itself.

With this model it is possible to merge values. Suppose that there are two different transactions that sends money to Bob. Bob might create a new transaction that has two inputs, and only one output, so they can be spent together. Similarly, it is possible to do joint payments very easily. For example, suppose that Carol and Bob both want to pay David. They can make a transaction with two inputs that are actually owned by two different people and combine the value to pay David. The only extra thing is that two separate signatures are required, one by Carol and one by Bob.

How Bitcoin transaction really look like

In the image above it is possible to see how transaction looks like, formatted like a JSON. In reality, it is a compact binary format that's not human-readable. But this representation is very, very close to the actual low-level transaction. It has three parts:

1. metadata: there are some housekeeping information. For example, the size of the transaction that corresponds to its dimension in bytes and not the amount of money. Then there's the indication of number of inputs and outputs. Then there's a hash of the entire transaction, which is its unique ID that will let us use hash pointers. There's also a lock_time parameter, which we will see in details later.
2. inputs: array of inputs of the same form. Every input refers to a specific previous transaction, or specifically to its hash and the index of output from the previous transaction the current is referring to. Then there's the signature, which is necessary to prove to be the owner of the previous transaction output.
3. outputs: array of outputs of the same form. The sum of all output has to be less than or equal to the sum of all inputs. Each output must go to a specific public key. Each output appears as a script that we will se in details later.