This article is an introduction into Blockchain
Technology, explaining the basics of Blockchains on
the example of Bitcoin. It gives an overview over
the challenges Bitcoin tried to solve and
illustrates the novel approach Bitcoin chose to
create a peer-to-peer payment solution. As the first
public and permissionless Blockchain, Bitcoin laid
the foundations of projects that followed in the
years after its launch, such as Ethereum for
example. Grasping the core concepts behind Bitcoin
provides thus a great base for understanding
Blockchains in general as well as more recent
Blockchain projects and to grasp the differences to
the Bitcoin implementation.
Posted: 06 May 2022
Introduction
The idea behind Bitcoin was made public in a whitepaper released in 2008, by a certain Satoshi Nakamoto. Until
today, the identity of the author of this paper remains unknown
and there exist more than a few speculations on who and where
Satoshi is.
This article however, is about the principles behind
Bitcoin, as they are described in the whitepaper, and
the actual implementation of the Bitcoin protocol. The
latter fuels the Bitcoin Blockchain, which has been live
since early 2009.
Bitcoin marks the first public and
permissionless
Blockchain network. Since 2009, a vast ecosystem of Blockchains
has emerged, with new projects joining the space every day.
But to understand how we got there, one should start with
Bitcoin. This is how this article is structured: It starts
with a closer look at the ideas and previously attempted
solutions that drove the conception of Bitcoin as a peer-to-peer
payment system. It follows a quick discussion about privacy
on the Bitcoin network and lastly, deeper insights will be
given into how the consensus mechanism, the much discussed
*Proof of Work* algorithm, works in the case of Bitcoin.
Core Idea
The core idea of Bitcoin is to remove any middleman from
a digital payment system. This is to say: digital
transactions would be sent directly from someone taking
part in the network to someone else, without a middleman
verifying the transactions or settling conflicts. This
is of course meant to strip this party in the middle of
any power it might possess, such as reverting
transactions for example.
However, just removing the bank will inevitably lead to
problems. Consider the following digital payment system:
Three participants, Alice, Bob and Charlie, can send
each other digital money through a bank.
The bank holds all account information and is as such
able to verify transactions. If Alice were to send $1.0$
coins to Bob, she would have to digitally sign a
transaction, and send it to the bank. The bank in turn
would verify the signature as well as Alice's account
balance to make sure she has sufficient funds to execute
the transaction. If those conditions are met, the
account balances of both Alice and Bob will be updated
accordingly.
The Intermediary
The problem with the intermediary, in the philosophy of
Bitcoin where one should not trust any third party, is
first of all that it holds and manipulates all the
balances as a monopoly. As such it can refuse
transactions and generate money at will. Banks are
certainly regulated but they may nonetheless change your
account balance. What is more, as a single point of
failure in the system, the bank processes all
transactions. If it were to fail, the other participants
in this network, Alice, Bob and Charlie, would not be
able to send money to each other.
Remove the Bank
In light of the problems described above, it is rather
natural to try and solve the problems by just removing
the bank. In this hypothetical system without a bank,
every participant in the network would have to hold a
copy of all accounts and their respective balances to be
able to verify transactions.
If Alice were to send the same transaction as in the
previous example, she would send a message to all
participants this time, including the amount she wants
to send as well as her digital signature. All parties
would verify the transaction according to their copy of
the account balances as well as the validity of the
signature and update the balances accordingly.
With everyone having updated their copy of the account
balances the same way, thus agreeing on the change the
transaction initiated, the network reached Consensus. This is essential for the system to work, consensus
amongst the participants has to be achieved.
Cheating the System
What would happen if Charlie tried to cheat the system
by increasing his account balance in his own copy of the
accounts by one coin and then sending one coin to Alice?
When verifying the validity of the transaction, Alice
and Bob would fail to verify that Charlie has the needed
amount and simply refuse to update the balances, even if
Charlie's signature was valid.
Thanks to the majority of the network agreeing on not accepting
such transactions, this fraudulent activity would be without
effect. It becomes more complicated if the majority were
to be malicious.
A way to break this simple system, is to perform what is
called a Replay Attack. Imagine Bob
copies the message Alice just sent (sending 1.0 coins to
Bob), and sends it to Charlie including a copy of
Alice's signature. Charlies would deem both signature
and balance valid and perform an update of the account
balances. Now both Bob and Charlie increased the amount
of coins held by Bob, thus representing the majority of
the network. Alice cannot counter this attack with the
simple rules of our system.
Serial Numbers and Transactions
A common concept introduced at this point are Serial Numbers. That is, numbering each coin and including the serial
number of the coin which is subject of a transaction in
the transaction message. In this case Bob would have to
modify the message and include a serial number of a
different coin Alice is currently holding. This
modification would make the signature on the transaction
invalid.
However, consider this: Alice could after some time come
back into possession of the same coin she sent earlier
with the transaction Bob has copied. Bob could wait for
that moment and then send the transaction again, keeping
a valid signature since he did not change the
transaction message.
And this is where Bitcoin introduces an intriguing and
novel concept: Transactions. By replacing the notion of Coins
with Transactions, the account balances
are no longer stored as the number of coins (with or
without Serial Numbers) someone owns, but as the sum of
the values of in- and outgoing transactions on that
account. It takes some time to wrap one's head around
it, but the advantage of offering protection against
Replay Attacks can be seen immediately: a transaction
holds basically the history of transacted amounts.
Consider the following example: Alice sends an amount of
$1.0$ coins to Bob. However, this time she sends a
transaction, named $tx_{11}$, which is the result of
$tx_1$, which points at Alice's account, transacting
$2.0$ coins to her. Transactions are conceptually made
of incoming transactions, and outgoing transactions,
where the sums of both have to be equal. In our case,
$tx_1$ had a value of $2.0$ coins associated with it. So
in order to match incoming and outgoing value, *$2$*
transactions will be created, one with $1.0$ coins
pointing towards Bob's account ($tx_{11}$) and another
one with $1.0$ coins pointing back to Alice's account
$tx_{12}$. The latter one basically represents the
change Alice is getting back.
Alice would broadcast the transaction to both Bob and
Charlie. They would in turn verify that transactions
with a sufficient amount point to Alice's account and
check if the signature is valid.
The following figure illustrates the network before and
after the transaction was sent and verified by the
participants.
To come back to the Replay Attack: Bob would now not be
able to send the same transaction again, since the whole
message of the transaction has changed and continues to
change on every transfer.
Double Spending
Up until this point, reasonable solutions existed before
Bitcoin that would prevent the aforementioned problems.
One challenge that remained unsolved was the protection
against Double Spending Attacks.
The following scenario illustrates such an attack. Alice
sends a transaction with amount $1.0$ coins to Bob and
at the same time a transaction with the same amount to
Charlie. If she sends the message about the first
transaction to Bob and another message about the second
transaction at the same time to Charlie, both appear
valid to the respective receivers. In this case both
would update their account balances and Alice would have
spent the same amount twice, while only paying once.
This obviously leaves the network in a state without
consensus.
To prevent double spending attacks, Bitcoin uses Public Announcements.
Public Announcements
The idea behind public announcements is simple:
broadcast any transaction to everyone on the network.
Meaning, you cannot select who will be the receiver of
your transaction. In Bitcoin this results in a pool of
unapproved transactions, where all broadcasted
transactions are collected.
A random network participant will be selected to
validate a transaction and send it to everyone else, so
they can update their local copy of the accounts.
Sybil Attack
This random peer selection has one problem: if we were
to choose all participants with the same probability,
someone could use multiple connections to the network to
be more often the selected participant to validate
transactions. This would enable them to favor their own
transactions for example. The described scenario is
called a Sybil Attack.
The key to solving this problem lies in the mechanism to
select the network participant who is to announce the
next validated transaction. Bitcoin introduces a
mechanism called Proof of Work,
implementing a selection based on computing power with
some random elements to keep the selection fair.
Although it does not render Sybil Attacks impossible, it
makes them at least sufficiently difficult to discourage
this kind of attack.
Proof of Work
To become the peer that is able to publish the next
validated transactions, all participants compete in
solving a cryptographic challenge. First, they collect
transactions from the pool of publicly announced
transactions. Then, they all try to solve a problem,
using the Proof of Work algorithm. Whoever si to find
the solution first, can announce the transactions. All
other peers can verify the solution to the challenge and
the transactions that are being broadcasted, which is
inherently less computationally intense as computing the
solution itself. Lasty, everyone can update their copy
of the transaction history.
The process described above deals in batches of
transactions. In the context of Blockchains, this is
described as the basic unit of a block.
Meaning that every time someone publishes new approved
transactions and a challenge solution, they effectively
publish a block. All blocks are linked to their
predecessors, in a way that modifying the order is
virtually impossible. This also serves as a means to
keep the transaction history clear, since accounts only
store transactions, not coins.
To do so, a block contains a Hash of the previous block
besides the transactions and the Nonce, which represents
the solution to the challenge.
In case two peers find the solution at the same time,
the chain splits, since both blocks are valid and are
linked to the latest block on the chain. For the next
block, peers can decide on which end of the chain they
want to work on in order to extend it. The general rule
is to work on the *longest* chain of blocks. As a
result, as soon as a new block is added to either of the
two blocks (without a 'competing' block at the same
time), this chain effectively becomes the longest chain
and all peers start to work on extending it.
Blockchain
The previous paragraph introduced the blockchain. It
represents a digital ledger, holding information about
all accounts and the transactions that point at those
accounts as last recipients. As such, it is possible to
verify a chain of transactions from the first ever
transaction to its current endpoint.
Another interesting property of this network is that
peers, called nodes, can drop in and out of the network
at any time without compromising its functionality. As
soon as they join again, they update their information
about the current state of the ledger and fetch pending
transactions. Then they start working on the longest
chain.
There is however, a possible attack that remains: a 51%
attack. This describes an attack where one party or
multiple collaborating parties possess more than 51% of
the computing power on the network. This would make it
more likely that a member of this malicious group
becomes the node that appends the next block, and would
thus be able to act maliciously.
To mitigate this risk, Bitcoin introduces incentives for
nodes solving the challenge, so called miners, to remain
neutral. Miners collect transaction fees from the
transactions they include in their blocks, making it
profitable to add blocks to the chain and behave. On top
of that, every new block (up until a certain point in
time), creates one transaction that sends a certain
amount directly to the miners account as a reward for
mining the block.
Thus, it becomes not only infeasible, but also
unprofitable to attack the network, since that would
also destroy the value the miners are receiving.
However, what makes the network inherently safe, is a
high number of miners. The more miners and ,more
importantly, the more decentralized the computing power,
the safer the network from 51% attacks.
Mining
Mining, as introduced above, is an essential part of
Bitcoin. And although often described as a
'cryptographic challenge' or a 'mathematical puzzle', it
really is all about brute force and luck.
The basic idea of the Proof of Work algorithm is the
following: before publishing a new block, one has to do
some kind of computation that requires computational
resources. Although this mechanism got popular with the
emergence of Bitcoin, it has been invented as a
protection against spam. Instead of being able to send
requests or emails for example immediately, the sender
has to use computing power and attach a proof that they
did the work to the message, only then it will be
treated. When sending one email or request, this
represents a negligible overhead. However, if you want
to generate thousands of those requests, it will require
massive computing power to send them all at the same
time.
Hash Function
The most important part of the algorithm is Hashing. A hash can be computed over any input, whether it is
a simple number or a file. The output of a hashing
function, the actual hash, is always of the same length,
no matter the input. Bitcoin for example uses a hashing
algorithm with a 256 bit output, which accordingly
outputs a number between $0$ and $2^{256}$.
Hashing functions have very interesting properties. For
one, they are *one-way* functions, meaning any input can
create a hash value as output, but it is not possible,
or at least not feasible to compute the input with a
given output. Moreover, a hash function should be collision free. That is to say, the function will never create
identical outputs for different inputs. These properties
are key in understanding why hashing functions are being
used in cryptography.
Bitcoins Proof of Work Algorithm
In the case of Bitcoins Proof of Work algorithm, the
mining software computes a Hash using the data contained
in the header of the block the miner wishes to add to
the chain. The header of a block holds information such
as the hash of the previous block, information on the
transactions included and a Nonce.
While most of the data in the header is fixed, the nonce
can be changed by the miner. This variation produces
different Hashes as output.
The output hash is then compared to a given value, which
represents the difficulty target of the problem. If the
computed hash is lower than the difficulty
target, the problem is solved and the miner may publish the
block. However, if the number exceeds the difficulty target,
the miner will have to retry, by changing the nonce and recomputing
the hash. This process is being illustrated by the figure
below.
When comparing computing power for miners, the most
important number is how many hashes per second the
machine is able to compute. Since, the more hashes you
try, the more likely you are to find a hash solving the
problem.
The difficulty of this algorithm, i.e. the average time
it takes to find a solution, can be guided by the value
of the difficulty target. The higher the target value,
the 'easier' it is to find a solution, since more hashes
satisfy the condition $Hash lt target$. The Bitcoin
protocol aims to maintain an average Block time
of 10 minutes. In order to achieve this, the difficulty is
being automatically adjusted every 2016 blocks (roughly 2
weeks), with regards to the current total
Hash Power of the network. The Hash Power
indicates how many hashes can be computed by all miners combined.
Since the output of the hash function cannot be
predicted, small miners, with little computing power,
also stand a chance in solving the problem through pure
luck. This incentivises users to join the network as
miners, even without a super computer.
Privacy
To round this article off, a quick note on privacy in
the Bitcoin network. Bitcoin itself does not grant you
full anonymity. This is due to how transactions are
being stored: visible to anyone on a public ledger. What
keeps you private is the fact that the sender and
recipient of a transactions are represented as a row of
numbers, addresses. This address is
associated with all transactions you receive and send
from a given wallet. As soon as someone is able to
associate a given address with a name, they are able to
trace all transactions ever made by that address.
It is of course hard to trace transactions, especially
if someone is to employ techniques of obfuscation, such
as using mixers for example. However, there is no
guaranteed privacy through the Bitcoin protocol.
This marks the end of this introduction into Blockchain
technology. If this catched your interest, there are
lots of topics to explore from here: Privacy,
Smart Contracts,
Decentralized Autonomous Organizations
and Stablecoins, to name just a few (feel free to use these
links to get down into the rabbit hole).
