by Chris Kamp, Clara Tan

Setting my eyes upon the white paper the first time, I personally found the first paragraph dense and foreign. I invited my friend Chris to join in the endeavor of taking the white paper apart into the smallest bits of logic and depicting the overall logic flow. Here’s our result!

From our perspective, the introduction explained the ‘why’ of Bitcoin. The rest of the white paper is a technical explanation/support of the ‘how’. In consequence, this document is presented such that section ‘1 Introduction’ deconstructs the claims made in Nakamoto’s ‘1 Introduction’. Then, ‘2 The rest of the document’ simply helps explain the white paper’s technical argument.

Finally, we’re new to the field. If you have corrections, edits, helpful suggestions, please comment below. Did any of this help you in any way? Perhaps you’d like to extend the discussion? Let us know!

— Clara

1 Introduction

For transactions between two parties over a communications channel (not in-person):

Logic flow of claims made in ‘1. Introduction’

The introduction makes the following claims (explicitly or implicitly):

Online commerce relies on financial institutions serving as trusted third parties to process payments.

a) Because nothing can be immediately, physically exchanged in an online transaction (e.g. cash), a trusted third party is needed as an intermediary.

b) Physical transfers of cash protect the seller because the cash cannot be taken back without external intervention. There are still risks, such as that the cash could be counterfeit, but this risk is minimised by making currency that is physically difficult to reproduce. Data, on the other hand, is easily copied, so some method to prevent double-spending is needed. One such method is to have a trusted third party (a financial institution) maintain a central database of accounts, and process all transactions.

c) In this system, a payer communicates with the financial institution, then the financial institution processes the payment and communicates to the payee that the payment has been validly made. The payee knows it will receive the payment because it trusts the financial institution (based on its size, reputation, history, etc.), whereas it would have no such reason to trust individual payers.

2. This trust-based model has inherent weaknesses, namely:

a) Completely non-reversible transactions are not possible, because financial institutions cannot avoid mediating disputes.

This doesn’t seem to be an inherent weakness of the trust-based model. There is no reason in principle why you couldn’t have completely non-reversible transactions in a trust-based model: financial institutions could simply refuse to mediate disputes and implement a policy of never reversing transactions in any circumstances. They could have strict preconditions before allowing a transaction to happen (e.g. the payer has to verify their identity to the bank), but once those conditions are met and the transaction occurs, it would be irreversible (even if later shown to be fraudulent).

There is no logical reason the trust-based system can’t work this way, but there are practical reasons. For example, in existing legal systems banks may bear liability where fraudulent transactions occur, meaning they bear risk if they do not allow transactions to be reversed.

b) Because disputes can occur and can be resolved by a decision to reverse or not reverse a payment, someone (generally the financial institution) needs to mediate those disputes and make the decision whether to reverse a payment. The cost of having systems for mediation and reversal of payments increases transaction costs, and higher transaction costs limit the minimum practical transaction size.

This is (the paper claims) a weakness of the trust-based system because: Payments in a trust-based system must be reversible (for reasons discussed above) > If payments are reversible, a system of mediation is needed to determine whether disputed payments should be reversed > The cost of implementing that system of mediation is a transaction cost > Higher transaction costs make very small transactions impractical.

Disputes and reversibility go hand in hand. If transactions are completely non-reversible, there are no “disputes” — a payer might feel they were defrauded, but there is nothing they can do to get their money back, so there is no real “dispute” to be resolved. And conversely, if transactions are reversible, there will always be disputes about whether a particular transaction should be reversed. Those disputes need to be mediated or resolved in some way, and that has costs.

A completely non-reversible payment system avoids disputes, because there is no real dispute about a payment unless there is a way to resolve the dispute (by reversing the payment).

Of course, even using a “non-reversible” payment system, there might be external forces that can effectively reverse payments — for example, courts may order a party to pay money back. So disputes about payment can still occur, eg. in the legal system, but they are external to the payment system itself.

Even this kind of reversibility could be avoided by either: (i) legal recognition for non-reversible transactions, so that the law will not intervene to reverse payments for specified types of transactions, even in cases of fraud; or (ii) anonymising transactions so that, even if there is a legal obligation to reverse a transaction, it is impossible to ascertain the identity of one or both of the parties so as to compel them to make repayment.

In general, it could be stated that a sense of liability causes disputes to ‘bubble-up’ — if transacting parties can not mediate, it can be elevated to the financial institution. Next, if the financial institution refuses to mediate, it can be elevated to a legislative body.

c) The inability to make non-reversible payments for non-reversible services is an additional cost.

This is referring to the scenario where the payee provides a service, the payer pays for the service, but then the payment is reversed. However, the service which has already been performed can’t be reversed — so the payee bears the risk and is out of pocket.

What if payments were completely non-reversible? Then the payer would bear the risk: both of fraud (where a payment is made from the payer’s account which the payer did not authorise) and of non-performance (where the payer pays for a service in advance, but the payee never provides the service).

Neither of these systems (reversible or non-reversible) seems obviously superior on the face of it, they are just different allocations of risk. However, the advantage of the non-reversible payment system is that there is no mediation of disputes, and no associated transaction cost.

In any case, as discussed below, even in a system with non-reversible payments, escrow mechanisms can be used to provide reversibility for particular transactions, effectively letting the parties choose where to allocate the risk.

d) Merchants must be wary of their customers and require more information from customers than they would otherwise need.

If payments are reversible, the merchant bears the risk of fraud (because, if a payment is fraudulent, it may be reversed). Therefore, the merchant is incentivised to make sure that payments are not fraudulent. How can they do this? Only by verifying the identity of customers carefully, either directly (by requiring information from customers) or indirectly (by trusting a third-party financial institution, which itself takes steps to verify customer identity by requiring information from customers).

Conversely, if payments are irreversible, customers may require more information about the merchant before making payments in advance, because they will not have the option of reversing the payment if the merchant does not actually provide the service (or does not do so to a high enough standard).

3. “A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency”.

a) There would still be some uncertainties in physical currency transactions. Someone could pay using counterfeit money (but the merchant has the opportunity to examine the physical currency to check for this). Someone could pay using stolen money, and it may be that in some legal systems the merchant could then be forced to pay the money back, making the transaction “reversible” in a sense.

b) But essentially, the risks are much lower and much less dependent on trust — the merchant has the physical cash in hand, and it can’t be taken back without the merchant’s involvement.

c) Conversely, from the customer’s perspective, the risks are greater in a non-reversible payment system (including use of physical currency) — any payment made in advance of the service being provided (or while it is being provided) cannot be easily reversed if the service is not provided or is not completed to an acceptable standard. So, as discussed above, whether transactions are reversible is largely a question of allocation of risk.

Check out this section in ‘point-form’ — do you have a preference towards one or the other?

2 The rest of the document

This section expands upon the rest of the white paper, a technical description of Bitcoin. It intends to aid the reader while covering every point made in the white paper. Much of this has been supplemented by Andreas Antonopoulos’ ‘Mastering Bitcoin’. Elsewhere, references are included by embedded links.

Mechanism

Bitcoin is sent to and received from a public address. A private key (not shared) is needed to accept (sign) payments to this address.

Many public keys can be generated from the same private key. It is in the interest of anonymity that different public keys are generated for each transaction.

A transaction is a record of Bitcoin input and output. Inputs are ‘from’ a sender and outputs are ‘to’ a receiver. The difference between the output and input makes the transaction fee. Each transaction is marked with a unique hash.

A transaction input is a previous transaction’s output, referred to by the transaction hash. To make a desired payment amount, multiple inputs can be aggregated. Else, where the input is larger than the desired amount, ‘change’ is sent back to the sender via the same or different public address. This is listed as an additional output. Multiple outputs also occur where the sender sends to multiple receiving addresses.

It follows that one’s ‘balance’ of Bitcoin is just a sum of unspent transaction outputs (UTXO) that can be unlocked by one’s private key. Outputs are never changed and are spent entirely. Therefore, there is never a need to completely trace a transaction’s history to track a balance value (referred to as ‘fan-out’).

A network is formed where nodes exist across CPU.

New transactions are broadcasted from node to connected nodes. A node must be able to connect to a few nodes to establish diverse paths into the network (as nodes come and go).

Nodes collect new transactions into a transaction pool. When a transaction is received by a node, it checks the legitimacy of the transaction, including that the output has not already been spent.

Some nodes are also miners. Miners create a candidate block which becomes proven by solving ‘Proof-of-Work’. Proof-of-Work is a problem that can be solved using CPU. The difficulty of the Proof-of-Work can be adjusted to set the rate at which blocks are proven, the mining rate.

Blocks contain header information that includes a timestamp, reference to the hash of the previous (parent) block in the chain, and the difficulty target of the Proof-of-Work for this block.

When a block is proven, its miner fills the block with its transactions in the transaction pool.

Proven blocks are broadcasted to the network. Each node checks the legitimacy of the block received. Also, if a transaction in its transaction pool is in the block, it is removed from its pool.

Proven blocks are chained in sequence by each node, so each node has a copy of the ‘blockchain’. Nodes attempt to slot the new block into the chain after its previous (parent) block, given by the block’s header information.

Usually, the parent is at the end of the chain, so the new block becomes the new end of the chain. However, the parent can sometimes be behind the latest block on the chain. The addition of the new block then forms a branch or fork called the ‘secondary chain’. Sometimes, the parent is not found on the chain and the block is saved as an ‘orphan block’ until the parent is received.

The longest chain is always taken to be the ‘main chain’.

Occasions occur where two proven blocks are broadcasted at nearly the same time in the network. Nodes receiving quicker say, proven block A vs. proven block B adopt A at the end of the main chain while those receiving quicker B adopt B. A and B likely, though not always, contain the same transactions.

Imagine that a node with blockchain ending with B now proves block C. Nodes ending with B simply add C to the chain. Nodes that ended in A now see that C also has B attached, and therefore forms a longer chain. Nodes ending in A now discard transactions in block A into its transaction pool, and adopt the longest chain, ending with BC. Soon, one of these nodes proves a block, so the dumped transactions become included in the longest chain. A becomes a fork for these nodes. In the event ADE is somehow received before BCF is formed, ADE becomes the main chain, and so forth.

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This is an incentive for miners to initially distribute coins into circulation.

Miners also receive the fees from every transaction. Once a predetermined number of coins (21 million) have entered circulation, the incentive transitions entirely to transaction fees. Because of a predictably constrained supply, Bitcoin is deflationary.

A wallet can exist at a partial node that communicates to full nodes. Partial nodes can verify transactions by simply keeping headers of the main chain. Partial nodes can not check the transactions themselves, but can query its place in the main chain. The partial node accepts the transaction if a full node has accepted it and there are six blocks added after it. Six blocks is an arbitrary amount of blocks. It is considered sufficient Proof-of-Work by proxy to ensure the transaction is not a double-spend.

Security, in the sense of a consensus attack

There are several security weaknesses of Bitcoin and one starting point is investigation via Bitcoin Wiki’s ‘Weaknesses’ page. The white paper discusses security in the context of a consensus attack (a.k.a. ‘51% attack’) and therefore claims “the system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes”.

What might a dishonest node want to do?

Reverse his own and others’ transactions

Prevent transactions from being sent

Change the number of coins generated per block

Create coins out of thin air

Send or receive Bitcoin that he isn’t entitled to

What can a dishonest node do?

Due to public-private key cryptography, he can only steal back his previous payments and potentially double-spend.

Prevent some or all transactions from being confirmed.

Prevent some or all miners from proving blocks.

Consider the cases:

a) Dishonest node starting the network (others are partial nodes)

Insecure

100% CPU

b) Dishonest node(s) appear after honest node(s)

Because the longest chain is the chain with the most amount of CPU, network is insecure if sum of CPU of dishonest nodes > sum of CPU of honest nodes. [Utility and sustainability of such a network? Honest nodes leave, dishonest nodes have a network with less value. Even if the honest nodes cannot communicate with each other, they’ll leave one by one provided they are able to, and dishonest nodes consume the network. I feel this is probably a common phenomena with a name….]

If sum of CPU of dishonest nodes < sum of CPU of honest nodes, fraud is less likely but can still occur. While known as a ‘51% attack’, Antonopoulos states that consensus attacks can occur with as little as 30% hostile CPU.

Consider for example, that a dishonest nodes tries to steal back his payment:

Mines the next proven block, where his transaction has been edited so that his payment was made back to himself, creating a fork.

A mined block is placed after that, so that the fork is taken to be the main chain.

Therefore, a consensus attack can occur whenever an attacker mines a fork, and that the fork gains blocks faster than the original chain. Consequently, it is easy to see that an attacker is exponentially less likely to be able to create the longer chain from more blocks behind.

The incentive program, where miners get one Bitcoin and/or fees for proving a block, aims also to deter attackers from fraudulent activity because it should be more profitable to earn new Bitcoin and/or fees.

As partial nodes only keep a copy of block headers, they are unable to check new transactions against all transactions and therefore, double-spends. Thus, partial nodes connected to attacker nodes are vulnerable. To avoid this, alerts could be sent through the network when an invalid block is detected, prompting the partial node to download the full block to confirm the inconsistency. Alternatively, only use full nodes.

Anonymity, in the sense of linking inputs/outputs

Anonymity can be compromised by means outside those discussed in the article. One starting point for further reading is Bitcoin Wiki’s ‘Anonymity’ page.

The consensus system requires that the time and size of transactions are publicly available. New public keys can be generated for every new transaction. Therefore, transactions are arguably not private but potentially anonymous.

Seeking anonymity, the first place to start is obtaining Bitcoin anonymously. Once this occurs, it is still possible to de-anonymise. A multi-input transaction necessarily reveals that each input was owned by the same owner. If one output address has never appeared in the chain, it is the ‘change’ address of the same owner. Linking through the chain reveals the other transactions belonging to the same owner.