Notes on Bitcoin

Below a few notes I took back in 2014 on Bitcoin’s original paper (link). I am currently reading “The Business of Blockchain” and found myself going back in my notes to review some of the concepts behind BTC, I figured it was worth putting it up for future reference as I am in the process of writing a less technical take on the blockchain in general.


Key idea behind bitcoin:

(1) Question: Transfer cash without going through a financial institution
(2) Challenge: Avoid double spending – a trust third party required in the transaction
(3) Solution: peer-to-peer distributed time stamp server to generate computational proof of the transaction

What its BTC attempting to fix?

  • Current transfer model: still suffer from the weaknesses of the trust based model
  • Completely non-reveresible transactions = not really possible ( cut off non reversible services )
  • Fin Institutions cannot avoid mediating disputes = cost of mediation increase transaction cost
  • Size of practical transactions increase = cutting off small casual transaction

How is it trying to fix it?

What is needed is an electronic payment system based on cryptographic proof instead of trust

  • impractical to reverse = protect sellers from fraud
  • escrow mechanisms = protect buyer

Risks associated with it?

Bitcoin network will work if the are as many honest CPU controlling the network then the group of hackers (a big hacker that has more then 50% may put an end to the system, however there are incentives in place to make him want to generate new coins instead of restarting the chain from a block in the past and benefit from double spending)

 


Key passages of the paper:

  1. Transactions
  2. Timestamp server
  3. Proof-of-work
  4. Network
  5. Incentive
  6. Reclaiming Disk Space
  7. Simplified Payment Verification
  8. Combining and Splitting Value
  9. Privacy
  10. Calculations

1- Transactions:

1844ABD2-B9F9-4A59-99AD-8935AA32099B

Problem: Owner 2 can verify that Owner 1 signed the coin but cannot know if the coin is also spent elsewhere (at each transaction you can know if the coin is coming from the legitimate party): double spending problem.

—> classic solution: introduce a trusted central authority that checks every transaction for double spending, so that the Owner2 will trust only coins coming from the central authority as they have been checked

—> problem: we will still need a central authority increasing costs and breaking the peer-to-peer network

—> workaround: need a way to know that the payee did not already sign the same coin, the only way is to be aware of all the transaction of that user, and consider only the earliest transaction to avoid double spending, to do it without a central authority all transactions must be publicly announced (and confirmed by the other party)

Therefore party must agree on a single history of the order in which they were received.

2 – Timestamp server

B4A81627-E87A-498E-8E51-486C4E499E0D

– take the hash and timestamp it
—> timestamp proves the data must have existed at the time, in order to get into the hash.
Each time stamp is included into the hash forming a chain.

3 – Proof-of-work

09F0EA56-105E-49C0-9A68-A8927FA9550B

The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

—>increment a nonce in the block until a value is found that gives the block’s hash the required zero bits
once the CPU effort is done, the block cannot be changed without redoing the work. (to avoid hackers to be able to sign coins before honest cpus)

To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. The probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

Security feature of Proof-of-work: If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.
The proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. (if they’re generated too fast the difficulty increases)

4 – Network

– New transactions are broadcast to all nodes.
– Each node collects new transactions into a block.
– Each node works on finding a difficult proof-of-work for its block.
– When a node finds a proof-of-work, it broadcasts the block to all nodes.
– Nodes accept the block only if all transactions in it are valid and not already spent.
– Nodes express their acceptance of the block by working on creating the next block in thechain, using the hash of the accepted block as the previous hash.

5 – Incentive

Since there is no central authority to issue them, the first transaction in a block is a special transaction and can be done by mining: Analogous to gold miners expending resources to add gold to circulation.

Costs: CPU time and electricity
>if output value (t1) of a transaction is less then input value (t0): difference is transaction fee(t1-t0) that is added to the incentive value of the block (t0).

This incentive is used also to protect the system: If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between

– using it to defraud people by stealing back his payments,
– or using it to generate new coins.

In that case there would be the incentive for him to play by the rules as the benefit would be larger

6 – Reclaiming Disk Space

Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. But storage should not be a problem.

7 – Simplified Payment Verification

Verified payments without running a full network node.
The trick is that you keep a copy of the block headers of the longest proof-of-work chain, which you can get querying network nodes until you are convinced you have the longest chain. You can’t check the transaction by yourself, but by linking it to a place in the chain, you can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. (i.e. you rely on the network knowledge to avoid wasting resources revalidating it)
—> As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.

8 – Combining and Splitting Value

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer.

9 – Privacy

The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.

49419069-CB5B-4BEE-941B-326F9ADE9898

 

10 – Calculations

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. An attacker can only try to change one of his own transactions to take back money he recently spent.

The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.

– The success event is the honest chain being extended by one block, increasing its lead by +1
– the failure event is the attacker’s chain being extended by one block, reducing the gap by -1.

Gambler’s Ruin problem.
Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows:

767C8CC6-923C-4CC9-81B1-4B41BC3AC335

Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.

The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn’t know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker’s potential progress will be a Poisson distribution with expected value:

7D9C8F24-B0E7-4E10-8217-0A607E794414

2E166A50-53C9-4069-8919-5DA29E198EB9

Comments are closed.