The news is by your side.

How Does Bitcoin Work?

0 1

Get real time updates directly on you device, subscribe now.

The Bitcoin blockchain is managed by software running on computers
that communicate with each other forming a network. Although multiple
compatible software implementations exist, the most commonly used
software is called ‘Bitcoin Core’ and source code to this software is
published on GitHub80. This software contains the full range of
functionalities needed for the network to exist. It has the ability to
perform the following tasks which will be explained in this section:
• Connect with other participants in the Bitcoin network
• Download the blockchain from other participants
• Store the blockchain
• Listen for new transactions
• Validate those transactions
• Store those transactions
• Relay valid transactions to other nodes
• Listen for new blocks
• Validate those blocks
• Store those blocks as part of its blockchain
• Relay valid blocks
• Create new blocks
• ‘Mine’ new blocks
• Manage addresses
• Create and send transactions
However, in practice, the software is usually only used for its
bookkeeping function, which will be explained in depth in this section.
To understand how Bitcoin works, and why it works the way it does, it is
important to keep in mind the objective: to create an electronic payment
system that cannot be censored, and to allow anyone the ability to send
payments ‘directly from one party to another without going through a
financial institution’.
Such a system cannot have a central administrator managing the ledger,
as that administrator would be the financial institution that Bitcoin is set
up to avoid. The system therefore needs to be able to be operated by
anyone, without any need to identify themselves or gain permission from
a gatekeeper. The moment that parties need to identify themselves, they
lose privacy and are vulnerable to interference, coercion, prison, or
worse. This goes for both administrators of the system and users
themselves. So every single part of the solution needs to work with these
constraints in mind.
How did Satoshi go about designing the solution? Let’s start with a classic
centralised model and then try to decentralise it. In this way, we can build
up the design of Bitcoin step by step.
Classic Centralised Model
Let’s start with a ledger which keeps tracks of balances, managed by an
administrator. You can think of it as a list with two columns: Account,

The administrator assigns account numbers to customers, and customers
make payments by instructing the administrator. There is an
authentication process where the customer proves that they are the
account holder before the administrator will carry out the payment
instruction. So each customer is named and, for security, has a password
linked to their account.

The administrator maintains the central record of balances and makes all
payments. They are responsible for ensuring that no one spends money
they don’t have or spends the same money more than once, the ‘double
But if we want resistance to control and censorship, and to allow anyone
to be able to transact with anyone else, we need to remove the
First, let’s remove the administrator from the account opening process,
so that anyone can open an account without needing permission from the
Problem: Accounts Need Permission
Someone has to set up an account and assign it to you. It is the
administrator’s job to assign you an unused account number then set you
up with some sort of username (which may be your own name) and
password so that when you ask the administrator to make a payment on
your behalf, the administrator knows it is really you making the request.
In setting up your account the administrator has granted permission for
you to open the account, and may, equally, choose to refuse that
permission. Any time you have an entity that can approve or deny
something, you have a point of third party control. We are trying to
eliminate third party control.
Is there a way you can open an account without having to ask
permission? Well, cryptography provides a solution.
Solution: Use Public Keys as Account Numbers
Instead of names or account numbers and passwords, why not use public
keys as the account number, and digital signatures instead of passwords?
By using public keys as account numbers, anyone can create their own
accounts with their own computer without having to ask an administrator
for an account number. Remember, a public key is derived from a private
key, which is a number picked at random. So you create an account by
picking a random number (your private key) and doing some maths on it
to get your public key. In Bitcoin and most other cryptocurrencies,
account numbers are mathematically derived from public keys (not
public keys themselves), and are called addresses.

You can tell the world this Bitcoin address to allow people to pay to it82.
No one can spend anything from it unless they have the private key,
which only you have. You can also create as many addresses as you want
and your wallet software will manage all of them for you.
Could someone else already be using an address that you randomly
picked? Possible, but unlikely. We saw in the cryptography section that
Bitcoin’s scheme uses a random number between 0 and
as a private key. There are so many private keys available that the
possibility of stumbling across someone else’s account is virtually nil. As
one commentator put it, ‘Go back to bed and don’t worry about this ever
happening’. 83
Public/private keypairs also solve the authentication problem. You don’t
have to log in to prove that you are the account holder. When sending a
payment instruction you digitally sign the transaction with your private
key, and this signature proves to the administrator that the instruction is
indeed coming from you, the account holder. You can create and sign the
transaction offline without being connected to any network. When you
broadcast the signed transaction to the administrator, all the
administrator has to do is check that the digital signature is valid for the
respective account number, rather than maintain a list of usernames and
passwords for you and all transacting parties.

Problem: Single Central Bookkeeper
We have now eliminated the role of the third-party administrator in
creating accounts. But we still have the third-party administrator in the
role of central bookkeeper—the coordinator who maintains the list of
transactions and balances and who both validates and orders the
transactions you request against some business and technical rules. This
single point of control ultimately decides what is reflected in your
account, whether your transaction goes through or not. As a single point
of control, it is classified as a financial institution, and has the regulatory
burden of having to identify you and all other customers, a process
known as Know Your Customer or KYC. It can also be coerced to censor
So, for a digital cash system resistant to third party influence, including
control and censorship, we need to remove that single point of control84.

Solution: Replicate the Books
The more people you have sharing a secure system and its information,
the less vulnerable that information is to manipulation. However, a group
of ‘trusted bookkeepers’ would inevitably require their own gatekeeper,
so we would be back to the central point of control problem again. The
solution is for anyone anywhere to be able to be a bookkeeper without
asking permission from anyone else and without hierarchy. And all
bookkeepers, wherever they are, maintain the same complete books of
record and are peers of equal seniority, with checks and balances such
that if any single bookkeeper were forced to try to censor a transaction or
manipulate the database, the others would ignore or exclude them.

As long as all bookkeepers maintain identical records of which
transactions are included and which excluded, we have a more resilient
system. If any individual bookkeeper is forced to stop work, the others
can continue. Anyone is able to join this network of bookkeepers without
needing permission from anyone else. So the network is resilient to
anyone joining or leaving at any time.
In Bitcoin, any individual with a computer, adequate storage, and access
to internet bandwidth can download some software (or write their own),
connect to a few neighbours, and become a bookkeeper.
New transactions are broadcast to all bookkeepers via a gossip network,
and each bookkeeper relays new transactions to as many others as they
are connected to. This ensures eventual propagation of transactions to all
Problem: Transaction Ordering
How do multiple bookkeepers stay in sync with each other? Every
bookkeeper will have a different idea of the order of transactions. Given
that there could be hundreds of transactions being created anywhere in
that there could be hundreds of transactions being created anywhere in
the world, and given that it takes some time for these to fully propagate
across the network, if every bookkeeper tried to put these transactions in
order, there would be many conflicting versions of the ‘correct’ order of
transactions. What happens if a bookkeeper in China receives transaction
A then transaction B, whereas a bookkeeper in the USA receives
transaction B first, then A?
Geography, technology, connectivity, internet traffic, servers, and
bandwidth all influence the speed and order in which transactions
originating anywhere in the world manifest themselves everywhere else.
Your ordered list of transactions as manifest, say, in London is going to
be very different from someone else’s list, even next door, let alone in,
say, Lagos, New York, Auckland, or Nairobi.

How do we get an agreed ordering of transactions?
Solution: Blocks
We can’t control how many transactions can be created per second, but
we can control the data entry into the ledgers. We can do this by
recording transactions in batches, page by page instead of transaction by
transaction. Individual transactions, validated as ‘pending’ transactions,
can be passed around the network, then entered into the books in less
frequent batches. We call these batches blocks!

Blocks are created much less frequently than transactions, so it is more
likely that a block reaches all bookkeepers in the network before another
one is created. This means that a bookkeeper now performs two
1. Validating and propagating ‘pending’ transactions
2. Validating, storing, and propagating blocks of transactions
By slowing down the ‘data entry’ process of the bookkeeping system,
bookkeepers around the world have more time to agree on the ordering of
blocks of transactions. So rather than all bookkeepers needing to agree on
the order of transactions, they need to agree on the order of blocks which
are generated less frequently. Because there is more time to agree on the
order of blocks, there are fewer differences in opinion about block
ordering, and so a greater chance of network-wide consensus. Later we
will see how the network deals with conflicting blocks.
Once your transaction is bundled along with other transactions into a
valid block, and that block is passed around the network, the transaction
is said to be ‘confirmed’ with one confirmation. When the next block is
added, on top of the block with your transaction, your transaction is
confirmed with two confirmations. As new blocks arrive on top of the
initial block, your transaction is deeper in the ledger and becomes more
and more confirmed. This is important because there are situations
where the very top of the chain, i.e., the newest blocks, may be replaced
by other blocks, kicking out transactions which looked like they have
already been confirmed85. We will look into the ‘longest chain rule’ later.
There is a trade-off between the ease with which bookkeepers can agree
on the ordering of transactions and the speed at which valid transactions
are written into the blockchain. Having blocks created, say, once per day
would make it very easy for all bookkeepers to agree on the ordering of
those blocks, but this is longer than people want to wait for their
transactions to be confirmed.
In Bitcoin, blocks are created every 10 minutes on average. Different
cryptocurrencies have different block creation target times.
Problem: Who Can Create Blocks, and How Often?
We have seen that it makes sense to batch pending transactions into
We have seen that it makes sense to batch pending transactions into
blocks that are propagated around the network. Bookkeepers add those
blocks to their own ledgers. As we will see later, if there are discrepancies
or competing blocks, they use the ‘longest chain rule’ to decide which
block wins.
Firstly, we need to manage the creation and frequency of blocks. How can
we do this? If one party gathers up all the pending transactions, puts
them into blocks, and sends the blocks to all the bookkeepers then we are
back to a single, centralised control point, which we have set out to avoid.
So anyone, without permission, needs to be able to create blocks and send
them around the network. But then how do we control the speed at which
blocks are created? How do we get a bunch of anonymous block-creators
to take it in turns and ensure that they don’t create blocks too quickly or
too slowly?
Could the bookkeepers themselves have a rule to accept blocks only a
minimum ten minutes after the last block they saw, to make it pointless
for someone to try to create blocks at more frequent intervals? Due to the
latency of the internet, this may create some unfair advantages (we don’t
know the precise time when any individual bookkeeper received the latest
block, and we can’t trust timestamps on blocks because these can be
easily faked), and we also can’t trust the individual bookkeepers who
might alter this rule, or their computer’s clock, and accept their own
blocks sooner than 10 minutes.
Perhaps, we could have a conductor, an entity whose job is to randomly
assign the next block-creator, who allows the next block to be created
only 10 minutes after the previous one? No, that would not work either,
as the conductor would be a central point of control over the network,
and we don’t want a central point of control.
So perhaps each block-creator could be randomly assigned, like rolling
So perhaps each block-creator could be randomly assigned, like rolling
some virtual dice so whoever gets a ‘double six’ is the next block maker.
But that wouldn’t work—how could anyone prove they have or haven’t
cheated? Who would roll the dice? How do we randomise the next blockcreator
and ensure that everyone agrees that it was a fair process?
Solution: Proof-of-Work
The solution is extremely elegant. The solution is that all block-creators
have to play and win at a game of chance, a game that in aggregate, over
the whole network, takes some specific amount of time to play (say 10
minutes on average).
The game must give all block-creators an equal chance of winning. The
game must not have a barrier to entry, else the gatekeeper would be a
central point of control. The game must not have shortcuts, and the game
needs to have a publicly displayable proof so that the winner can prove
they have won. The game must not be cheatable.
The prize? Being allowed to create the next block.
The game of chance that Bitcoin uses is called ‘proof-of-work’. Each
block-creator takes a bunch of transactions that they know about, but
which have not yet been included in any previous blocks, and builds a
block out of them, in a specific format. The creator then calculates a
cryptographic hash from the block’s data86. Remember that a hash is just
a number. The rule of Bitcoin’s proof-of-work game of chance says, if the
hash of the block is smaller than a target number, then this block is
considered a valid block which all bookkeepers should accept87.
What if the hash of the block is bigger than this number? Does the
specific block-creator bow out for this turn? No. The block-creator needs
to alter the data going in to the hash function and try hashing the block
again. They could do this by removing a transaction from the block, or
adding a new transaction, or changing the order of transactions in the
block, but these are not elegant and eventually you might run out of
permutations. You don’t really want to mess around with the transactions
in a block.
The solution in Bitcoin is that in every Bitcoin block there is a special part
of the block that block-creators can populate with an arbitrary number.
Its only purpose is to allow block-creators to fill it with a number, and
change the number if the hash block doesn’t meet the ‘hash is smaller
than a target number’ rule. So, if the first hash attempt doesn’t result in a
winning hash, then they can just change the number in this part of the
block. This number is called the ‘nonce’ (number once) and is completely
separate from the financial transactions in the block. Its only job is to
change the input data for the hash function.

So each block-creator puts together a block and fills the nonce field with
the number and hashes the block. If the result meets the ‘hash is less than
a target number’ rule for valid blocks, then they have created a valid
block, and can send it to the bookkeepers, and get to work on the next
block. If the result doesn’t fit the rule, then they change the nonce (e.g.,
by adding 1) and hash again. They do this repeatedly until they find a
valid block. This is a process known as mining.
This is elegantly described as a scratch-off puzzle in a paper by Miller et
al entitled “Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin
Mining Coalitions”88. Like scratch-off lottery cards, each miner has to
expend a bit of effort scratching off a puzzle to see if they have a winning
So the authority to create a valid block is not given by a third party but is
self-assigned by repeating some tedious mathematical algorithms, which
all computers can do89. Note that mining is a tedious, repetitive job. Take
some transactions with the nonce, hash it, see if the hash is smaller than a
certain number, and if not, repeat with a different nonce. It is not ‘solving
complex mathematical problems’ as is widely described in the media.
Hashing is easy but boring! You can even do it by hand using pencil and
paper if you have the patience, though you would be unlikely to win a
block with only these tools to power you. Ken Shiriff did a round of
hashing by hand with pencil and paper without a calculator, and you can
watch him do it on his blog90.
In this way, anyone can be a block-creator and create valid blocks. They
then send the valid blocks to the bookkeepers. The only thing that the
bookkeepers have to do is to take the block, including the nonce, and
hash it once to verify for themselves that the hash of the block is less than
the target number.
Proof-of-work also avoids another kind of attack, a Sybil attack. A Sybil91
attack is when a network is overwhelmed by multiple forged identities all
under the control of a single actor. Think Facebook or Twitter bots…
loads of usernames but all under control of a small number of bad actors.
In Bitcoin, your chance of winning a block is proportional to how much
hashing power you control. In the Bitcoin whitepaper this described as
‘one-CPU-one-vote’. If Bitcoin had given each node (each block-adder) an
equal chance of winning a block (one node, one vote), the Sybil attack
would be to create unlimited numbers of block adders and try to win all
the blocks. Creating multiple identities is very cheap for attackers to do.
So proof-of-work works well as a solution to this kind of Sybil attack
because proof-of-work is computationally expensive, and this in turn
means expensive in terms of electricity and hardware (i.e., cash), which
means it is expensive to try to overwhelm the network with hashing
power, which in turn increases the attack costs to a bad actor. If you have
all of this hashing power available, you might as well put it to work
finding blocks and making money (well, bitcoins) instead of trying to
subvert the network, so the theory goes.
Problem: Incentivising Block-Creators
But all of this tedious hashing needs resources: computers, electricity,
bandwidth… and this all costs money. Why should anyone bother
creating blocks? What’s in it for them? How can we incentivise the blockcreators
to create blocks and keep the system running?
Solution: Transaction Fees
The solution is to pay the block-creators for their time and resources! But
who is going to pay them and in what currency? An external payment or
incentivisation mechanism, i.e., a third party paying the block-creators,
would centralise and gate the process, defeating the purpose of
would centralise and gate the process, defeating the purpose of
censorship resistance, so that will not work. US dollars or any fiat
currency would not work either, as fiat is held in bank accounts and
banks can be instructed to freeze accounts.
An internal or intrinsic incentivisation scheme avoids third party control.
This is implemented as a per transaction fee, so the block-creator gets a
commission, a small amount of value, from each transaction. This could
be specified as a percentage or a flat rate for all transactions and encoded
into the rules of the system—a bit like the ‘10 minutes per block’ rule. But
it is difficult to establish the right fee. Bitcoin’s solution is a market-based
approach where people creating transactions add their own voluntary
transaction fees, and the block-creators can prioritise those transactions
with higher fees over those with lower fees.
When Alice creates her Bitcoin transaction she can optionally add a fee
that is collected by the lucky who mines her transaction92. This fee allows
miners to prioritise her transaction over others, who are all competing to
get in a block. Blocks are limited by network rules, as to how much data
can squeeze into a block. In Bitcoin, this limit is nominally 1 MB93. Fees
tend to go up in times where there are many transactions queuing up to
get into blocks, and down again in times with fewer transactions.
Problem: How to Bootstrap?
How were block-creators incentivised to keep creating blocks in the early
days or, indeed, now during slack periods when there may be periods
where there are no transactions for some hours? The hashing work
consumes electricity and costs miners’ money.
Solution: Block Rewards
The second, and currently much larger, incentive for block-creators to
create blocks is the ‘block reward’. In effect, the block-creator can write a
cheque to themselves once per block, for up to a certain amount. The idea
is that block rewards can kick start the system, and then be phased out
gradually, with transaction fees to replace them.

The very first transaction in a block is called the coinbase transaction94.
This coinbase transaction is special because it is the only transaction that
creates bitcoins. All other transactions move bitcoins between addresses.
The block-creator can create a transaction that pays any address (usually
themselves) any number of bitcoins, up to a limit specified by the Bitcoin
protocol. This limit was 50 BTC per block in 2009 and reduces by half
every 210,000 blocks, which at 10 minutes per block, is about every 4
years. Currently (mid-2018) the maximum block reward is 12.5 BTC, with
the next reduction to occur on block 630,000, estimated to occur in May
202095. These block rewards have created around 17 million bitcoins to
date, and owing to the repeated halving of the block reward, the
maximum number of bitcoins created ever will be a sliver under 21
million, the last of which should be created a little before the year 2140.
Unless the rules change.
This block reward is the mechanism that keeps block-creators creating
blocks. They receive valuable BTC in return for spending resources doing
the tedious hashing to create valid blocks. Note that block-creators are
under no obligation to include any transactions in their blocks, but they
choose to because the transactions themselves contain transaction fees
and these also accrue to the block-creator.
The beauty of this system is that the payment for creating blocks comes
from the protocol itself rather than from an external third party.
Problem: More Hashing, Faster Blocks, More Monetary Supply
If anyone can create valid blocks by finding the nonce that makes the
hash of the block meet a certain criterion and get paid for it, then surely
by throwing more computers at the hashing they can create valid blocks
more quickly and get paid more! By doubling the amount of hashing
power, they can, on average, double the speed at which they can create
valid blocks.
But this, unchecked, would cause havoc. With more people throwing
more hashing power (i.e., computers) at the block creation process,
blocks would be created faster and faster. Remember, we want blocks to
be created slowly, so that the bookkeepers have a better chance of staying
in consensus. And BTC would be created faster and faster, creating a huge
supply and possibly decreasing the value of each unit.
Solution: Difficulty
The network needs to self-correct and slow down if blocks are created
more quickly than the target of one block every ten minutes. The answer
more quickly than the target of one block every ten minutes. The answer
lies in changing the target number for the hash calculation. Variations in
this target number can make it easier or harder for the network, in
aggregate, to find hashes that fall below this number. As an analogy, if
you have to roll two dice and get a sum total below eight, that is quite
easy, but if you have to get a sum total below four then that will take you
more rolls. So making the target number smaller slows down the rate at
which valid blocks are created.
In Bitcoin, the target number is mathematically calculated from a
number called the ‘difficulty’. The difficulty changes every 2016 blocks
(which takes about two weeks at ten minutes per block), according to a
formula that uses the elapsed time it took to mine the previous 2016
blocks. The faster the previous 2016 blocks were created, the more the
difficulty increased. The difficulty and the hashing target number are
inversely related, so as difficulty increases, the target number becomes
smaller, making it harder and therefore slower to find valid blocks.
The network is beautifully self-balancing. If more hashing or mining
power is added, then blocks get created faster for a period of time until
the next difficulty change, after which it becomes harder to find valid
blocks, slowing block creation down. If mining power leaves the network,
then blocks take longer to be found, until the next time the difficulty
changes, then difficulty decreases, and blocks become easier to find. And
this is all done without a central coordinator.

Problem: Block Ordering
Transactions are bundled into blocks which are like pages in a ledger.
These blocks are passed around the network at a slower rate than
individual pending transactions would be. But how do you know what
order the blocks should be? In a book, each page has a unique page
number, and you know that the pages follow in ascending order. If the
pages fall out, you can put the book back together again in the right order.
Could the same be done for blocks where each block gets a unique ‘block
number’? In principle, yes, but remember that block-creators are
competing to mine blocks by hashing their contents and seeing if the
competing to mine blocks by hashing their contents and seeing if the
hash is smaller than a target number determined by the current difficulty.
Imagine that the block 1,000 has just been mined and passed to all the
nodes. The miners start mining block 1,001. Someone super sneaky might
get to work mining block 1,002 and to try to get ahead of competitors, so
that as soon as someone else has found block 1,001, they can submit
block 1,002 and claim the block reward. Remember, the miner doesn’t
need to populate any transactions in the block, they can just hash an
empty block 1,002 that refers to block 1,001 with a coinbase reward
transaction and no other transactions. Hmm, that wouldn’t be a good
idea, there’d be all sorts of gamesmanship.
What restricts miners to ensure they mine only the very next block? How
is ‘mining ahead’ prevented?
Solution: A Block Chain!
Instead of having each block have a ‘block number,’ each block refers to
the previous block by its hash. Miners must include the previous block’s
hash in the block they are creating.
This means that to mine block 1,002, miners need to know the hash of
block 1,001. Until 1,001 has been mined, 1,002 can’t be mined. This
forces miners to focus on block 1,001, which in turn includes the hash of
block 1,000, and no miner can skip ahead. Thus a chain of blocks is
created, held together not by block numbers (which can be predicted) but
by block hashes (which can’t). Each block refers to a previous block by the
previous block’s hash, rather than by a number that goes up sequentially.
This is the chain of blocks, or blockchain.

An additional benefit of blocks linking through their hashes is that of
internal consistency, sometimes described as immutability. Let’s say the
latest block that has been passed around the network is block 1,000. If a
rogue bookkeeper attempts to tamper with a previous block, say, block
990, and attempts to republish that block to other bookkeepers, they
1. Publish block 990 with new data but using the old hash; or
2. publish block 990 with new data and a new valid hash (i.e., ‘re-mine’
the block).
In the first case, the block will be considered invalid by all other
bookkeepers, because it is internally inconsistent (the block’s hash
doesn’t match the data inside it), and in the second case, the hash of
block 990 won’t match the reference found in block 991. Thus, it is very
hard to get away with tampering with any records that already form part
of the blockchain—it will be immediately obvious to anyone who you try
to convince. This is what is meant when blockchains are described as
immutable. Of course, nothing is immutable (can’t be changed), but
blockchains are tamper-evident—that is, it is easy for others to tell if data
has been modified, accidentally or otherwise.
Problem: Block Clashes / Consensus
There is still a chance that blocks are created by different block-creators
at the same time, due to the random process of hashing. If a bookkeeper
receives two valid blocks from two different block-creators (miners) and
they both reference the hash of the same previous block, how does the
bookkeeper know which one to use and which one to throw away? How
does the network come to consensus about which block to use? And if a
miner receives two valid but competing blocks, how do they know which
block to build the next block on?
Solution: Longest Chain Rule
There is another protocol rule called the longest chain rule97. If a miner
sees two valid blocks at the same block height then they can mine on
either block (usually the first seen) and would keep the other one ‘in
mind’. Others will also make their decisions and eventually one of the
blocks will have another block mined on it, then another, and another. So
the rule is that the longest chain is the chain that should be considered
the chain of record, and the block that is discarded is called an orphan.
What happens to the transactions in the orphaned block? They are
considered as if they have never been part of a valid block and therefore
are ‘unconfirmed’. They will just be included in later blocks along with
other unconfirmed transactions, assuming they don’t conflict with the
transactions that have already been confirmed in the blockchain.
Problem: Double Spend
Although the longest chain rule seems sensible, it can be used to create
mischief in a deliberate double spend. Here is how you could do it:
1. Create two transactions using the same bitcoins: one payment to an
online retailer, the other to yourself (i.e., to another address you
2. Only broadcast the transaction that is the payment to the retailer.
3. When the payment gets added in an ‘honest’ block the retailer sees
this and sends you goods.
4. Secretly create a longer chain of blocks which excludes the payment
to the retailer, and replaces it with the payment to yourself.
5. Publish the longer chain. If the other nodes are playing by the
‘longest chain rule,’ then they will reorganise their blockchains,
discarding the honest block containing the payment to the retailer,
replacing it with the longer chain you published. The honest block is
said to be ‘orphaned’ and, to all intents and purposes, does not exist.
6. The original payment to the retailer will be deemed invalid by the
honest nodes because those bitcoins have already been spent in your
longer, substituted, chain. You will have received your goods but the
payment to the retailer will be rejected by the network.

Solution: Wait About Six Blocks
Therefore, common advice for people receiving bitcoins is to wait for the
transaction to be a few blocks deep (i.e., to have a few blocks mined on
top of it). This gives comfort that the transaction is settled and can’t easily
be unwound98. At this point the amount of mining that has to be done to
create a competing chain longer than the existing chain is enormous,99 so
rational miners would prefer to dedicate their hash power towards
creating legitimate blocks, receiving the block reward and transaction
fees, rather than trying to subvert the network.
To put it another way, it is deliberately hard to generate a valid block.
Therefore, if someone wants to replace blocks, they have to create blocks
quickly and overtake the rest of the (presumably honest) network. This is
another reason why people say Bitcoin’s blockchain is immutable and
cannot be changed. However, if more than 50% of the total hash power of
the network is used to re-write blocks, then it will be able to do so,
because it will create blocks faster than the other, less powerful, half. This
is called a 51% attack. Smaller amounts of hash power can also be used to
re-write the blockchain, but with a lower probability of success100. 51%
attacks have been successfully performed on unpopular coins with few
Which Coins?
Earlier, I used the phrase ‘using the same bitcoins’. What does this mean?
With physical cash, each coin or banknote is a unique object. You can’t
pay the same coin or banknote to two people. However, digital money
doesn’t work that way. In a traditional bank account, all your money is
mixed up or co-mingled in a ‘total balance’ figure. Your income goes into
the bank account and is immediately jumbled up with all the other money
that is in there, like adding water to a half-full bath. When you make a
payment your total balance is reduced, like removing water from the
bath. You cannot specify which dollar you are spending. For example,
when you pay $8 for a coffee, you don’t say, ‘Use $8 from my salary
payment that came in on 25 Jan,’ you just say, ‘Use $8 from the pool of
money that is my account balance’. This non-specificity promotes the
fungibility of digital money, that is, one dollar in an account is exactly the
same as another.
Bitcoin is digital, but it works more like physical cash. With cash you
open your wallet and take this specific $10 note which you received
earlier and pay $8 for your coffee and expect $2 change. Bitcoin is
similar: for every payment you make, you have to specify exactly which
coins you are spending—that is, which specific bitcoins that you received
earlier. You refer to these received bitcoins by the transaction hash101 that
sent the coins to you. In the same way that blocks build on each other by
referring to the previous block’s hash, transactions also refer to each
other using a previous transaction’s hash. When you make a Bitcoin
payment, you say, ‘Take this bundle of money that came in to my account
in this transaction, and pay some of it to this account and return the
change to me’.

Here is a Bitcoin transaction102. You can see that it takes 1.427 bitcoins
from address 17tVxts…QM and sends 0.5999 bitcoins into 1Ce2Qzz…wK
and returns 0.827 bitcoins back to 17tVxts…QM. But wait… The two
payments add up to less than the amount spent. 0.5999 + 0.8270 =
1.4269 which is less than the 1.427 spent. The 0.0001 Bitcoin difference is
the mining fee. The miner can add that 0.0001 to the coinbase
transaction in the block and pay it to themselves.
If we look at the block the transaction is included in,103 we can see that the
miner paid themselves 12.52723951 bitcoins in the coinbase transaction,
which is the 12.5 BTC block reward plus the sum of the transaction fees
from the transactions in the block:

Hence all bitcoins are traceable. You can see the exact composition of
every lump of Bitcoin that comes into your account—what it is composed
of and where it came from—and you can trace every part of that money
via the previous accounts, all the way back to when it was first created in
a coinbase transaction.
I say each ‘lump of money’ specifically, rather than ‘each Bitcoin,’ because
you don’t send bitcoins coin by coin, you just send a total amount. Let’s
see how this works with an example.
Let’s start with an empty address and assume that you are friends with a
Bitcoin miner who has just created a ‘lump’ of 12.5 BTC in a coinbase
transaction when they successfully mined a block. The 12.5 BTC is like a
single banknote in a physical wallet and needs to be spent in its entirety.
The miner takes pity on you because you have no bitcoins and wants to
give you 1 BTC. So the miner creates a transaction spending those 12.5
BTC to two recipients: 1 BTC to you, and 11.5 BTC back to herself. You
now have a 1 BTC ‘lump’ in your account.
Now it is your lucky day and a few other people give you BTC. In further
separate transactions, you receive ‘lumps’ of 2 BTC and 3 BTC. So now
separate transactions, you receive ‘lumps’ of 2 BTC and 3 BTC. So now
you have 6 BTC in your wallet, in three lumps: 1 BTC, 2 BTC, and 3 BTC.
If you want to give 1.5 BTC to another friend, how would you do that? You
could do it in a few different ways:
Option 1: Spend the 2 BTC lump
You’d create a transaction that looks like this:
Spend: 2 BTC lump
Pay: 1.5 BTC to your friend, 0.5 BTC lump as change back to yourself
Option 2: Spend the 3 BTC lump
You’d create a transaction that looks like this:
Spend: 3 BTC lump
Pay: 1.5 BTC to your friend, 1.5 BTC lump as change back to yourself
Option 3: Spend the 1 BTC and 2 BTC lumps
You’d create a transaction that looks like this:
Spend: 1 BTC and 2 BTC lumps
Pay: 1.5 BTC to your friend, 1.5 BTC lump as change back to yourself
Option 4: Spend the 1 BTC and 3 BTC lumps
You’d create a transaction that looks like this:
Spend: 1 BTC and 3 BTC lumps
Pay: 1.5 BTC to your friend, 2.5 BTC lump as change back to yourself
Option 5: Spend the 1 BTC and 2 BTC and 3 BTC lumps
You’d create a transaction that looks like this:
Spend: 1 BTC and 2 BTC and 3 BTC lumps
Pay: 1.5 BTC to your friend, 4.5 BTC lump as change back to yourself
Although Option 1 feels like the most obvious and is probably what you
would do if you were spending banknotes in a physical wallet, you could
in theory choose any of those options. These are all different transactions
but all achieve the same thing. The lumps of money that sit in your
account are called ‘UTXO’s which stands for Unspent Transaction
Outputs. Most people think in terms of ‘account balances’ (i.e., my
account goes up and down) whereas Bitcoin ‘thinks’ in transactions (the
transaction spends this money and puts it there). The lumps are the
result or output of a transaction, and they are unspent because you
haven’t spent them yet. Bitcoin would describe Option 1 as follows:
Option 1: Spend the 2 BTC lump
Transaction inputs: (this is money that is being spent)
1. 2 BTC lump
Transaction outputs: (this is money that is not yet spent)
1. 1.5 BTC to your friend
2. 0.5 BTC lump as change back to yourself
This whole transaction is hashed, giving it a Transaction ID which can
then be used by future transactions. If you later want to spend the 0.5
BTC you returned to yourself, you would say ‘take output (2) from this
transaction, and spend it like this…’
Now, assuming you did Option 1 described above, what is left in your
account? You started with lumps of 1, 2, and 3 BTC. You spent the 2 BTC
lump and got 0.5 BTC back. So you’re left with three lumps: 1 BTC, 3
BTC, and the new 0.5 BTC lump. The blockchain records that the 0.5 BTC
lump came from yourself, so anyone can trace the 0.5 BTC lump back to
its original 2 BTC lump, and then further trace it to the account which it
came from originally.

What next?
The transaction is created and signed by the sender using their private
keys. This signed transaction is then sent to a node (bookkeeper) who
validates it according to business rules (e.g., Does this UTXO exist? Has it
been spent before?) and technical rules (e.g., How much data does the
transaction contain? Is the digital signature valid?), and if found to be
valid, the bookkeeper keeps this transaction in a pool of ‘unconfirmed
transactions’ that they have heard about, called a mempool or memory
pool. They then propagate this transaction to their neighbours in the
network. Each neighbour follows the same process. Eventually a miner or
block-creator picks up this transaction and decides whether they want to
pack it into a block, and if so, they start mining the block. If the miner is
successful in mining the block, they propagate the block to other miners
and bookkeepers and each node records this transaction as confirmed in
a block.
When people say Bitcoin is ‘peer-to-peer’ what do they mean?
Firstly, data is sent between bookkeepers in a peer-to-peer way, i.e.,
directly and not via a central server. Transactions and blocks are sent
between bookkeepers who are each as important in status as each other—
that is, they are peers. They use the internet to send data between
themselves, instead of a 3rd party infrastructure like the SWIFT network
used by major banks.
Second, Bitcoin payments are often described as peer-to-peer (i.e., with
no middle man). But is this really true? Up to a point. A physical cash
transaction is definitely peer-to-peer as there are no other actors other
than the payer and the recipient. But Bitcoin also has intermediaries such
as miners and bookkeepers. The difference between Bitcoin payments
and bank payments is that, with Bitcoin payments, the intermediaries are
non-specific and can act in lieu of each other, whereas traditional banks
and centralised payment services are specific intermediaries. For
example, if you have an account with HSBC you can’t instruct another
bank such as Citibank to move your money, but in Bitcoin any miner can
add your transaction to a block they are mining.
Peer-to-peer models of data distribution are like a gossip network where
each peer shares updates. Peer-to-peer is in many ways less efficient than
client-server, as data is replicated and validated many times, once per
machine, and each change to the data creates a lot of noisy gossip.
However, each peer is independent and the network can continue
operating if some nodes temporarily lose connectivity. And because there
is no central server that can be controlled, peer-to-peer networks are
more robust and resistant to shutdown, whether accidental or deliberate.
In anonymous, and therefore untrusted, peer-to-peer networks, each peer
needs to operate on the basis that any other peer could be a bad actor. So
every peer needs to do their own homework and validate transactions and
blocks, rather than trusting other peers. The network as a whole acts
honestly, if populated by a majority of honest nodes. Next, we examine
the limits of bad behaviour and the related costs and incentives.
What can and can’t miscreants do?
The impact of a malicious bookkeeper is very limited. They can withhold
transactions and refuse to pass them to other bookkeepers, or they can
present a false view of the state of the blockchain to anyone asking them.
A quick check with other bookkeepers will reveal any discrepancies.
Malicious miners can cause a little more impact. They can:
• Attempt to create blocks that include or exclude specific transactions
of their choosing.
• Create a double spend by attempting to create a ‘longer chain’ of
blocks that make previously accepted blocks become ‘orphans’ and
not part of the main chain. They can realistically only do this if they
command a significant proportion of the entire network’s hashing
But they can’t:
• Steal bitcoins from your account, because they can’t fake your digital
• Create bitcoins out of thin air, because no other miners or
bookkeepers would accept this transaction.
So the impact of a malicious miner is also actually quite limited.
Furthermore, a miner discovered to be enabling double spends could
quickly find themselves cut off from the rest of the network if the rest of
the network informally agrees to take action. Honest miners might agree
not to build on blocks generated by a malicious miner.
Transactions are payment instructions of specific amounts of Bitcoin
(UTXOs) from one user-generated account (address) to another. The
transactions are created using wallet software, authenticated with unique
digital signatures, then sent to bookkeepers (nodes) who individually
validate them according to some well-known business and technical
rules. The bookkeepers then add valid transactions to their mempool and
distribute them to other bookkeepers that they are connected to.
Miners gather these individual transactions into blocks and compete with
each other to mine their blocks by tweaking the block contents,
specifically the nonce field, until the hash of the block is smaller than
some target number. The target number is based on the difficulty setting
at the time, which is derived from the time taken to mine the previous set
at the time, which is derived from the time taken to mine the previous set
of blocks to achieve a network-wide target frequency of one new mined
block every 10 minutes. Miners receive a financial incentive in the form of
new BTC and transaction fees which they may credit themselves, to
compensate for spending resources to perform the competitive, repetitive
hashing needed to create valid blocks.
The blocks link to each other in a unique sequence to form a ledger, the
Bitcoin blockchain, that is recorded identically almost simultaneously on
thousands of computers around the world that run Bitcoin software. If a
Bitcoin transaction is not recorded on this blockchain, it is not a Bitcoin
transaction. It doesn’t exist. A Bitcoin transaction recorded outside this
file does not form part of the ledger.
There is no central authority who controls the ledger or who can censor
specific transactions.
Different blockchain platforms or systems work differently. If you relax or
change the aims or constraints, the design of the solution can also
change. The solution may be simpler, as we will see later with private
blockchains where censorship resistance is not a critical factor.

Get real time updates directly on you device, subscribe now.

Leave A Reply

Your email address will not be published.

Subscribe to our newsletter
Sign up here to get the latest news delivered directly to your inbox.
You can unsubscribe at any time

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More