Bitcoin Internals, Part 2

12 minutes read

In this installment we’ll be talking about Transactions. As we already know a Bitcoin Block contains a Header and a collection of Transactions. We’ve already learned about how important Headers are and how they constitute a back-linked block-chain that helps to maintain the integrity of recorded transactions. Now the two new questions are: What does a Transaction look like? and How do we use it to transfer coins from address to address? And just like in the previous article I’ll be presenting a simplified C++ code here, while the real C++ code will be pointed to via links to Bitcoin’s GitHub repository.

Transaction’s Structure

Without wanting to make your reading experience more complicated than it already is, I’ll start with the unpleasant fact first: actually, there are two types of transactions! Regular ones and Coinbase Transactions. And they can be found in each block, side by side. And yes, there’s a reason for that, but before we go any deeper into that matter, let’s first examine the regular transaction’s structure only. This will surely help us a lot to understand more easily the Coinbase Transactions later.

Field	Role	Type
Version	Indicates the Transaction Format Version	numeric
NumberOfInputs	Number of Entries in the Collection of Inputs	numeric
CollectionOfInputs	Collection Input Entries (BTCs to redeem)	vector of objects
NumberOfOutputs	Number of Entries in the Collection of Outputs	numeric
CollectionOfOutputs	Collection of Output Entries (BTCs to spend)	vector of objects
LockTimestamp	Time-Window allowing the Transactions to be replaced in this Block	numeric

At the first sight this complex structure isn’t in any way helping us to understand how a BTC can find its way from sender to recipient. However, if we recall that “Bitcoin thinks in Transactions only” then the whole structure becomes a little clearer. Bitcoin has no senders, recipients or any kind of entities that own BTCs. Transactions are the only available entity that can be used to reclaim a possession of bitcoins!

Therefore, to send a BTC to an address we first have to prove that we’ve successfully redeemed this BTC from a previous Transaction output that’s now a Transaction input in the current Block. Or more technically: to be able to put a certain amount of BTC into the output vector of our Block we must have been able to redeem the same amount of BTC from some previous output vector. It doesn’t have to be a single output as only the final amount of BTC counts. We could also have redeemed BTCs from several previous Transaction outputs just to create a single Transaction output in our own Block. What’s important is the equilibrium between the incoming and outgoing amounts of BTC. Therefore, to understand how those two collections work together we have to dissect their structures as well.

Transaction Inputs & Outputs

A Transaction Input is a structure that comprises of a hash key, an index number, signature script length indicator, the response script, and an input sequence number.

The first two values, hash key and index number, are being used together to uniquely identify some previous output we want to redeem in our own Transaction. As we’ve already approached hashes in the previous article, and also have used them to uniquely identify our blocks, the question here is: Why do we need hashes and index numbers within transactions? Let’s look at the structure of Transactions in the picture below:

As we can easily recognize a Transaction hash key alone wouldn’t be precise enough to select the correct input BTC within a certain transaction. A collection of outputs within a Transaction mostly contains many entries, so we have to point at the right index number within. In the above picture we see a single entry in the left box but there could be hundreds of them. In the right box we see the Transaction input collection that points back to the previous Transaction output collection by selecting one of its entries by using an index number. This is how we create new Transactions: 

a) Refer to a previous Transaction by using its Hash Key (green)

b) Redeem certain Bitcoins by using index number(s) to point to one or more entries that belong to previous’ Transaction output collection (red)

c) Create a new entry in your own Transaction input collection (this effectively makes incoming BTCs available to you, because you can now create new entries in your own Transaction outputs)

We remember, Bitcoin thinks in transactions only and the above process is the way how Bitcoin’s blockchain moves BTC from one address to another. Before you can spend any Satoshi you must first point to it in any of the previous transactions and deliver a proof that you’re its owner. 

Ownership

Now that we’ve learned how a certain BTC can be found on the blockchain the next question that comes to mind is: How do we safely store and redeem our BTCs?

The answer lies in the entries from the above structure I deliberately avoided to describe: Public Key Script, Response Script, and their length indicators. Each time one claims to be the owner of some BTC a certain script will be executed to check if the claimant can provide needed signatures to redeem and/or spend those BTC. And following the nature of Bitcoin this too is done via Transactions only. This is the reason why transaction inputs & outputs contain certain scripts. However, they don’t get executed like those scripts from our operating systems, for example. Blockchain scripts aren’t shell-scripts or Batch-files. Quite the opposite. Input and output scripts must be executed pairwise. This is because every output script imposes a certain challenge to be solved by its input counterpart.

Described in a more simplistic terms, an output script defines a challenge: “this 1BTC belongs to anyone who is in possession of a private key that can generate this signature I’m carrying with me“. On the other side, the input script would solve this challenge by executing its own script-part thus generating data for comparison. Therefore, the BTC claimed in any input script can be taken from an output script by providing a solution to a certain challenge. We could describe Blockchain as a chain of back-linked blocks that supports a flow of values chained together by back-linked challenge/response scripts.  

Script

However, we’re not done yet as there’s something else that must be used to process those scripts: Bitcoin’s Scripting Language itself. Yes, it’s true, Bitcoin has it’s own scripting language. It actually has no specific name, so everyone calls it simply “Script”. It is a programming language but not like the most of those in use today. It’s not a turing-complete language which means that you can’t write programs or arbitrary complexity, for example those that contain loops. The inventor of Bitcoin, Satoshi Nakamoto, didn’t want Bitcoin to rely on a language that could be (mis)used to execute any kinds of programs. Just imagine a script containing a never ending for-loop thus effectively postponing all other operations on the Blockchain to some later date around the end of the known Universe. Bye, bye Bitcoin!

Therefore, certain powerful concepts, like loops, have been deliberately excluded from Script’s design. However, do not think that Script is a “crippled” language incapable of doing anything meaningful. It’s actually very flexible one as it comprises of several powerful commands for fast signature evaluation, de/encryption, verification and so on. We won’t be discussing Script in this installment as it deserves an article on its own. What’s important to know is that during each transaction a certain amount of logic (a program) gets evaluated by using a scripting engine that runs on Bitcoin’s blockchain.

Coinbase Transactions

So, after having learned about transactions and how we can move Bitcoins from address to address the whole Blockchain “stuff” should be no problem for you anymore, isn’t it? Well, one thing is missing and this is the actual creation of bitcoins? Where do bitcoins come from? Is there any “primal transaction” that has created all bitcoins in the past? Well, the answer is no. Bitcoins have not been pre-generated in some distant past, but they continuously get created by mining new Blocks. Each and every Block contains a special transaction called Coinbase Transaction whose sole purpose is to generate new bitcoins without resorting to some previous output Transaction entry. Unlike “normal” transactions that contain certain challenge scripts that have to be solved by response scripts, those new bitcoins come out of nothing and therefore have never had any previous “holders”.

Bitcoin’s blockchain needs new blocks to stay alive. But those blocks don’t get generated because “it’s funny” to create them, or because Bitcoin is some nice “social network” that everyone wants to participate in. Bitcoin and it’s blockchain constitute a real business that generates billions of dollars/euros/whatever-fiat. And these days we need lots and lots of computing power to mine new blocks. Certain entities, mostly big companies, who are capable of producing and/or installing specialized hardware for mining blocks, want to be rewarded for their work. And their rewards are those new bitcoins from Coinbase Transactions. Therefore, whenever a new block gets mined the miner who has created this block will add a special transaction and assign a certain amount of bitcoins to him/herself. This is the reward for the miner who has taken care of including our transactions, executing our scripts, and forwarding our bitcoins from address to address. This whole process is vital for Bitcoin to exist. Without mining no blocks can be created and without proper rewards no one would want to mine Blocks in the first place. Therefore, think of BTCs in Coinbase transactions as incentives to create blocks. Because every miner wants to be the one who inserts its own address into the Coinbase Transaction Output the competition keeps the system alive.

Bitcoin users want to move their bitcoins around and miners want to get fresh bitcoins. And not only coinbase BTCs, because miners also get a certain share of BTCs for each transaction they put into new Blocks. This is called a “transaction fee”. All in all, Bitcoin is not only a technology, but also a social contract that comprises of certain entities and incentives.

Now the first question regarding the above code would be: Why does the Coinbase Transaction contain Hash and Output Index values if there’s no need to redeem some previous output BTCs? The answer is simple: The values are the same for all Coinbase transactions. Hash value is always 0 and index is 2³²-1.

The really important part is the Coinbase Script that stores the current block height which means the number of the current block. If you imagine the blockchain as a sequence of stacked blocks the current height would be the block on top this stack. Additionally, the Coinbase Script can contain arbitrary data that is also being used to generate more randomness which is used when solving the Proof-Of-Work puzzle.

In this article we won’t be talking about Proof-Of-Work, so just keep in mind that miners can use the available free store inside the Coinbase Script to create additional data that helps them get more randomness which is of great importance when solving Proof-Of-Work puzzles.

In the above image we see that each time a new Coinbase Transaction is created the miner inserts a new challenge script that’ll be used later to redeem those new BTC. As a Coinbase Transaction takes no already existing bitcoins but introduces new ones, anyone who can provide a solution to the Challenge Script is the owner of new BTC. This is usually the miner itself.

And the last question we have to answer in this article is: How many BTC a miner is allowed to assign to itself? The answer is: It depends. There is a hard-coded rule that controls the current mining subsidy. Every 21000 Blocks, or roughly 4 years, the subsidy halves. At the beginning of Bitcoin, in 2009, the subsidy was 50BTC per Block. It then halved in 2012 to 25BTC. Currently, the subsidy is 12,5BTC per Block.

Additionally, the miner assigns a certain amount of transaction fees collected from the transactions included in this block. The whole sum is what miners expect to get when mining new blocks. This is how bitcoins come into existence. And the maximum amount of all bitcoins that can be created will be slightly less than 21.000.000. 

Conclusion

I hope that the whole process of creating Transactions, moving BTC around, and mining Blocks is now a little bit clearer. I know, the technique behind is complex and not that easy to explain, so we can only consume it bit by bit. In future articles we’ll come back to transactions, but with more details regarding the scripting language.