Mr. Di Giorgio, there are high hopes for blockchain technology. It even has the potential to make banks redundant. Why?
Blockchain has solved a fundamental problem of the digital finance world – the problem of double-spending. The internet works according to the copy & paste principle. Anything digital can be copied and multiplied: photos, songs and – in theory – money. Banks now take measures to prevent us from duplicating money in this way. They guarantee that money sent from my account will be credited to the beneficiary’s account.
And how can blockchain technology solve this double-spending problem?
To understand how, we need to go back a bit and start with the basics on which blockchain technology is based. The payment process consists of two basic elements that ensure that transactions can only be completed once. One of these elements is hashing, a cryptographic function used to calculate the checksum (see illustration below for the signature and verification process).
Hashing makes it impossible for data to be changed retroactively. Here’s how it works: if I want to sell a digital dataset such as an e-book, I need to make sure that the correct dataset (i.e. the digitised book) is actually referenced. I can use the hash algorithm to calculate a checksum for the dataset. This checksum is effectively the book’s digital fingerprint. Only this digital fingerprint, rather than the data itself, is sent in the blockchain – the e-book file is saved in a separate location.
The fingerprint has two key characteristics.
To ensure the authenticity of the files, the hash of a document is always included in the transaction.
And the second basic element of the blockchain?
The second element is the digital signature. This is based on an asymmetric cryptographic procedure that differentiates between a public key and private key (see illustration below for the lettering process in transactions).
Let’s assume that I want to send the digital fingerprint of my diamond. To do so, I need to make sure that no one can change the dataset (by using a hash) and that I am the only one who can determine who will receive this data.
Each member of the blockchain has a private key and a public key. With the private key, I can create a unique digital signature – I encrypt the hash that will be sent and ‘sign’ it with my key. I also send my public key to the recipient of the digital fingerprint in the transaction itself. The public key is derived from my private key and enables my signature to be verified. The recipient thereby receives the hash for the digitised diamond.
It also allows the recipient of the public key to verify that I am the only person who could have signed this hash. Only my public key can produce the same hash as the one created when running the diamond’s digital fingerprint through the Sha-256 algorithm. This allows ownership rights to be clearly disclosed in the blockchain.
However, it is impossible to guess from the public key what the corresponding private key looks like, as the former is created using a similar procedure to the one used by the hash algorithm to generate the character string.
So no one will know my private key?
Exactly. The transaction recipient only receives the public key and is informed that the hash has been signed. The public key can therefore be used to prove that this signature could only have been created by the owner of the private key.
So how do these cryptographic procedures relate to the blockchain?
These cryptographic technologies have been around for decades, but they previously didn’t have anything to do with bitcoins and blockchains. So the question is: how can they be used to trade money?
Let’s imagine that I want to send 10 bitcoins (BTC) to person A. To do so, two basic requirements would have to be met: firstly, I must own the money, and secondly, it may only be sent once.
Transactions in the blockchain (see illustration below) always have two different elements: inputs and outputs. So that I can send them the money, person A must provide me with their bitcoin address, which is nothing more than the public key that they have generated. I now have all the information needed to start a new transaction.
Source: Bitcoins the hard way from Ken Shirriff on righto.com, adapted by Gottlieb Duttweiler Institute gdi.ch
I write the following in the transfer: person A is receiving BTC 10 from me. I attach an output element (i.e. person A’s public key) to determine where the BTC 10 will go.
As with real funds, I must prove that I actually own the money that I want to spend. A transaction whose output is signed with my public key must exist somewhere in the blockchain, and because I am the owner of the right private key, only I can use this output as the input for my new transaction. I create a signature for the output using my private key, then add a public key, which shows that the output belongs to me and that I am now using it as the new input.
This enables each member of the blockchain network (known as ‘nodes’) to see that the transaction originates from me (through the signature with my private key) and that only I can use this preceding output. Person A can now do the same with the output that they have received from me and can use it again as the input for new payments. Each transaction is therefore linked to the previous one.
How can someone send more money than they have available in a single output?
If I want to send BTC 300, then this quantity of bitcoins must be registered somewhere in the system in different output elements. I therefore put several input elements into a transaction: (BTC 10 + BTC 150 + BTC 140 = BTC 300). This also works the other way round, of course, and I can spread my money across different public keys.
What if someone steals the private key – can the same money be spent twice (once by the thief and once by the legitimate owner)?
One of them would win. One transaction would be approved, the other one wouldn’t. The most recent transaction would be rejected by the system because the input element has already been used.
How does the system know which transaction occurred first if the two transactions were initiated at the same time?
To explain this, I’ll again need to go back a bit. Transactions are first collected and sealed in a block: a hash is created from the most recent block as soon as it is full. The checksum is stored in the block that is built next (see illustration below). This enables all previous blocks to be secured – any changes to an old block would change the hash of the block.
Transactions can be created by anyone who has downloaded a digital wallet in the form of an app. And they don’t have to be a full node in the network to do so, as that would mean they would have to download the entire blockchain and play an active part in verifying the transaction. This is only done by full nodes or by miners.
Thus, after I have created a transaction and it is recognised by a node, it moves into the live pool (the area where transactions are queued before being added to a block). The nodes then perform some initial checks: Is the transaction correct? Do the sums of the inputs and outputs correspond? Do the signatures match? They also verify whether there is another transaction with the same input. During these initial checks, the fastest transaction wins and the slower one is rejected as invalid.
Exactly. And each transaction is only added to the blockchain once the block is complete and has been secured with the checksum. This is where the proof-of-work consensus algorithm comes in. It ensures that the block is correctly accepted by the entire network.
A miner publishes their newly created block consisting of transactions that they have verified. Other miners verify the block, which is always one megabyte large and contains 2,000 transactions. As soon as these checks have been completed, the miners move on to the next block. They are therefore competing: the first one to create a block receives a reward. That’s why they mine bitcoins. There is a direct correlation here too: the lower the bandwidth, the slower the mining. A better computing power offers better chances of success and thus greater rewards.
And in which order are the transactions from the live pool added to a block? Since the size of the blocks is limited, the live pool will presumably contain more transactions than can fit into a new block.
This is a common cause of disagreement. The live pool expands, which means that a transaction can sometimes get stuck in it for several days. This is especially frustrating if you want to use bitcoins to buy a coffee, for example.
That’s why lightweight nodes (or Simple Payment Verification nodes) were introduced for smaller amounts. The SPV nodes don’t verify all transactions for a block, only those with a limited time horizon. ‘Short transactions’ (e.g. paying for coffee) usually require a certain degree of trust: I trust that you aren’t a hacker and are not trying to buy a coffee with money that you don’t have.
Because the transaction is only officially stored in a block afterwards, the payment is much faster – even if only provisionally. That’s why sellers only offer this payment method for smaller amounts. For larger transactions, they usually require the transaction to be verified by a full node and secured in a block.
Could you explain again how miners earn money for their work? They seem to be an essential part of the blockchain process.
The miners receive bitcoins from two different sources. As soon as a miner has calculated a block and it is lined up in the chain as the next valid one, they can perform what is called a coinbase transaction. The miner can add their own public key to this transaction and will receive BTC 12.5 (current rate) as soon as their block has been accepted.
These bitcoins are newly generated, which is why the process is referred to as mining. The miner can re-use the output received in this way as the input for new transactions. The entire blockchain can therefore be traced back to these first coinbase transactions.
Why does a miner currently receive BTC 12.5? Does this rate ever change?
Yes. Bitcoin began in 2008. Satoshi Nakomoto, who is believed to have invented it, wanted to make the cryptocurrency a scarce resource. That’s why the reward for mining a new block decreases by half every four years or every 210,000 blocks. The rate was BTC 50 at first and then BTC 25 from 2012, before falling to BTC 12.5 last summer. By around 2140, the rate for a block will have shrunk to BTC 0. That’s when the miners will have mined all 21 million BTC.
Because the work of the miners is so essential for the blockchain, they must have an additional incentive: transaction fees.
Anyone who places a transaction in the live pool can pay the miners bitcoins for their work. To do so, the input must be larger than the output. The miner can then assign the remaining money to their public key. Each trader in the bitcoin blockchain can decide whether to pay transaction fees or not.
So the more they pay, the faster the transaction will be processed?
Yes, that’s the incentive for the miners. They will naturally prioritise those transactions that promise the highest fees. Creating such a marketplace for transactions was the inventor’s original intention. However, he didn’t expect the transaction fees to rise so quickly. Today, the bitcoin community is fervently debating the best method for tackling this problem.
Increasing the size of the blocks doesn’t seem to be a viable solution. It is exiting to observe how the whole bitcoin community tries to solve such governance issues.
Christian Di Giorgio is a technology advisor at Swisscom. As a computer scientist and business economist he supports major companies to process ICT solutions.