A Beginner’s Guide to Bitcoin (Part 8): Mining

Previous Article   –   Next Article   –   Table of Contents


At the start of this article I said that none of the ideas in Bitcoin were that difficult.  However, there are a lot of things going on here already, and we haven’t even described mining.  So I’ve written a brief recap of the what we’ve covered so far in describing Bitcoin for those who are a little confused.  If you’re not confused, read on.

Slow It Down

We’ve said that Bitcoin as described so far would probably not work because it would be too chaotic.  We need one final ingredient to make it work.

This is to slow down the payment processing.  We make it take a lot of time for a computer to create a new valid block to add to the ledger.

In fact Satoshi Nakomoto set up Bitcoin so that the payment processing was very slow when compared to the time needed to copy payments and the state of the ledger around (the network latency).

In the original paper payments were put into blocks that were at most 1MB in size. This isn’t very big, typically it’s about a few thousand payments at most.  Bitcoin was set up so that one of these blocks would be added to the ledger every ten minutes on average.

Let me reiterate that Bitcoin processes slowly and that this was deliberate, by design, and without it Bitcoin would not work well, at least in its current form.  It turns out that it didn’t need to be as slow as the ten minutes for 1MB in the original paper, but the point still stands.

Effects of Slowness

The idea of this slowness was that every computer in the network should have seen all the results of the last round of payment processing before the next round completed.  This means that even if there are multiple versions of the ledger everyone should usually see all of them, and choose the biggest one (in terms of number of blocks processed) as the valid one.  This also means that most of the time the payment processing will be done only on the current valid ledger, and there will be few orphans.

It also makes it difficult to rewrite the ledger with payments that you like.  It takes time you won’t have to create new versions of the ledger that are bigger than the current one.  We’ll talk more about this later.

How To Slow It Down: Puzzles!

I’m sure you’re wondering how can we deliberately slow the payment processing down?  We’re deliberately trying to make computers do something slowly, after all.

The answer is that you get the payment processors to use their computers to solve time-consuming mathematical puzzles.  They can only add payment to the ledger if they’ve solved a puzzle and prove that they’ve done it.  This also means that they only get paid if they solve a puzzle.

Puzzle Features

For the puzzle you obviously you need something that will take some time, but where the result can be easily checked.  You also need new puzzles all the time, and not ones that can be solved in advance, or that you might have seen before.

You really want to be able to control the amount of time it takes to solve the puzzle on average with a given set of computers.  Network latency isn’t likely to change much, and remember the aim here is to slow down the payment processing relative to network latency.  Your new money may take off, and you may have lots of people trying to solve your puzzles and thus solving them more frequently.  You need to be able to make the puzzle harder so the overall time is as slow as before.

So They Called It ‘Mining’…

Of course, if you want to be taken seriously with your new cryptocurrency you’re not going to call this activity ‘puzzle solving to introduce a deliberate time delay’,  although that is absolutely what it is.

So they called it ‘mining’.  And they called the payment processors ‘miners’.

Mining Puzzles

I hesitated to include a description of the puzzle, because it’s a bit mathematical and it isn’t strictly necessary to understand it.  If you’re not interested in the details skip to the summary below.

Basic Puzzle

The puzzle is that we choose a number, any number, and add that into the block of payments we are trying to process.  We call the number we choose the ‘nonce’.

We then take the binary representation of the block including the nonce.  All data in computing has a binary representation that allows the computer to store it in memory and manipulate it.  This ‘binary representation’ is just a big number (in binary).

Note that we base this big number on the block of payments which means we get different unpredictable puzzles every time.  This is the only reason we use the block of payments.

We then apply a specific mathematical process called ‘cryptographic hashing’ to the big number.  This converts it into a shorter number.  I discuss why we do this below.

If the resulting hashed number is less than a certain threshold we are done: we’ve solved the puzzle.  If not we choose a different nonce, add it into the original block of payments, and try again.  We try different nonces repeatedly until we solve the puzzle.

Of course this is all done very quickly by a computer, so to make it take some time it has to be very hard to find a nonce that will solve the puzzle for a given block.  The computer will have to try a lot of nonces to solve the puzzle.


We use hashing in our puzzle as described above because it has certain properties that mean it’s impossible to cheat.  We have to solve the puzzle by brute force repeatedly trying values for nonces.

In particular it’s impossible to reverse a hashing algorithm, and there are no patterns or other properties of the hashed number that mean we can somehow work out what changes to the nonce will give a small hashed number.

Note that hashing is a common technique that is used for all kinds of things in computing and cryptography, not just for this.

There are several mathematical hashing algorithms that have the properties we need.  The one used in Bitcoin is called SHA-256.


So to ‘mine’ we set our computers to select a nonce, hash, and check the result repeatedly until they find a result less than the threshold, at which time we have solved the puzzle and have a valid block that can be added to the ledger.

The beauty of this approach is that to slow down the payment processing all we have to do is make the threshold for the result of our hashing smaller.  In fact Bitcoin automatically resets the difficulty to ensure that it takes ten minutes on average for a block to be produced.  It does this every 2,016 blocks, which is about two weeks since it’s about ten minutes to produce a block.

Checking That The Puzzle Was Solved

Once a block is complete, with a completed puzzle, it can be submitted to other computers.  The nonce is included in the block that is published, so it’s easy for the other computers to check if the puzzle has been solved.  They just apply the hashing algorithm once to the block they’ve received and check the result is below the threshold.  They should only accept the block if this test works.  They should also check the validity of payments in the block as discussed previously.

Summary: Proof of Work

  • The payment processors (the miners) have to get their computers to solve a puzzle based on the set of payments (the block) they are trying to add to the ledger.
  • They can only add the block and get paid if they solve the puzzle.
  • This puzzle can only be solved by repeated trial and error by a computer, and will take some time.
  • The results of solving the puzzle are easily checked, and the other miners will check them before accepting the block and adding it to the chain.
  • We do this to slow down payment processing when compared to network latency.

In the original paper on Bitcoin this process was called ‘proof of work’: the miners are proving that they’ve tied their computers up for ten minutes or so doing ‘work’.  This is ‘work’ in the sense of a pointless throwaway activity though.  It’s not useful work.

Mining: Have We Solved The Problem?

The answer to whether the puzzles solve our problems is that we haven’t so much solved them as mitigated them to the point where they aren’t really an issue.

General Operation

It’s still possible to have multiple versions of the ledger at any given time.  However this gets much less likely. The combination of the difficulty of creating a block and only getting paid for a block on the final valid ledger ensures this.

Why We Don’t Get So Many Versions of the Ledger

Suppose all our miners have the current version of the ledger and a new payment arrives.  They will all start working on trying to create a new block with the new payment.  After about ten minutes one of them will succeed.  This is likely to be copied to the other miners before any of them has found their own block, since the copy is relatively quick.

As soon as they see the new block the other miners are highly incentivized to switch to that version of the ledger and to try to create another new block.  That is, they will abandon trying to create the previous block.  This is because even if they do complete their own block the chain created by the first block will have a head start in terms of processing done on it.  It is likely to end up longer and hence become the valid ledger.  The miners are not likely to get paid for carrying on mining the old block.

Two Versions of the Ledger are Still Possible

Of course it’s possible that two miners will create two different blocks with the new payment nearly simultaneously.  Since it’s now relatively fast to copy the new blocks around the network it’s possible that most miners will see both blocks nearly simultaneously.  In this case they will probably pick one at random as the ‘valid’ one and work on that: there’s no point in splitting their processing power.

It’s then possible that two more blocks will be created nearly simultaneously by different miners, one on each chain, and the process could continue.  You can see that because it takes a long time to find a block, and the time is variable, this is far less likely than without mining, and eventually one chain is almost certain to get longer.

Confirmation of Payment

However this does mean that it’s still hard to be sure that a payment has been added to the final valid ledger.  Even if one miner’s ledger is showing a payment as processed in their valid ledger it’s possible that another longer chain will emerge which doesn’t have the payment.  That is, it could be rolled back effectively.

For this reason in the original Bitcoin the rule of thumb was to see that your payment was on the nearest ledger and then wait an hour, or six blocks, to ensure it wasn’t rolled back.

Note that these days unless you add quite a large transaction fee to your payment instruction it may never hit the ledger at all.  The miners have so many payments to process all the time that they prioritize those with fees and completely ignore those without.  This is a totally different issue to the one above.

Double Spend

For the same reasons double spend becomes hard.  We expect that even if two different payments are processed for the same coin by different miners then within one hour only one will be in the valid ledger of all the miners.  All we have to do is wait a bit before delivering any goods for a payment.

Manipulating the Ledger

Again, for the same reasons it becomes hard for a miner to manipulate the ledger.  If a miner wants to write their own chain with their own data they have to be able to make it valid and longer than the one that the rest of the miners are working on.  This is normally impossible because it requires huge amounts of computing power to mine faster than all the rest of the miners.

51% Attacks

Having said that, double spend and manipulating the ledger are still possible.  This is the ‘51% attack’.

A ‘51% attack’ is a theoretical problem with Bitcoin that can occur if one miner has control of more than 50% of the computing power in the network.  There have been no actual 51% attacks on Bitcoin, although other smaller cryptocurrencies have seen them.

Ledger Manipulation

If a miner has 51% of the computing power it means that they can create a valid ledger with the payments they want to see faster than the rest of the miners put together.  Note that this doesn’t mean they are guaranteed to always mine the next block.  Broadly they have a 51% chance of doing that.

However they can include the payments they want in a block and mine the block.  When the block is mined the main valid chain created by the other miners may be longer.   However now they can carry on mining on the chain that they have created with their block.  If they do this they are guaranteed that their chain will eventually be longer than that created by the rest of the miners, since they have more computing power.  Their chain can become the valid ledger if it’s published.

Double Spend

This can be used for a double spend, for example.  The miner posts a payment instruction paying some of their coins to someone.  At the same time the miner creates a block with a conflicting payment paying the same coins to themselves.  They mine this block and create a chain with it on, but don’t publish it.  They continue mining on this chain with all their processing power.  They wait for the original payment to be confirmed and the goods to be sent.  Then they publish their previously hidden longer chain that pays the original coins to themselves.   This effectively reverses the payment, but they already have the goods.


There’s a built-in mitigation for this however.  Any miner who did get 51% of the computing power would probably not want to start manipulating the ledger.  If such manipulation came to light it would probably kill Bitcoin.  No-one would trust a payment system where one anonymous person could reverse any payment they liked.  By the time a miner has 51% of the computing power they are making good money from their mining, so destroying the currency may not be that attractive.

Previous Article   –   Next Article   –   Table of Contents

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s