Bitcoin white paper
Tags: web3, blockchain, learning, cryptocurrency
Published: 2024-05-11 07:21:48

I read the Bitcoin white paper. Here's what I learned



## Abstract


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3osaodls0w08jaehp8g0.jpg)


- Objective: To introduce electronic cash, allowing online payments without a third-party institution.
- In the physical world, you would give money/note to someone, and now you can't use the same money/note again.
- But in electronic cash, there could be double spending. Precautions must be taken so that the same electronic cash is not used again.
- You might say, "Don't bank/UPI services record this?" But then we are involving a third-party institution.
- So, a solution is proposed using a peer-to-peer network. Where instead of a central authority (single point of failure), if the majority of the CPU power is genuine, then the longest chain is taken as proof of what happened.



## Introduction

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ow5ecmclinu4qlckab8e.jpeg)
- The model involving third-party institutions suffers from the weakness of trust.
- Third-party institutions cannot avoid mediation. The cost of mediation increases transaction costs, cutting off the possibility for small casual transactions.
- With the possibility of reversal, the need for trust spreads. Hassling more information for a transaction than needed.
- All these costs and payment uncertainties can be avoided in person by using physical money, but require physical presence.
- Solution proposed: an electronic payment system based on cryptographic proof instead of trust.
- Completely non-reversible transactions with a peer-to-peer distributed server to generate proof of transactions.
- It is secure, as long as nodes collectively control more CPU power than any cooperating group of attacker nodes.


## Timestamp Server


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/loivo4671rsvw32skfj6.jpg)
- A timestamp server works by taking a hash of a block of items to be timestamped and publishing the hash.
- The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.
- Each timestamp includes the previous timestamp in its hash, forming a chain.
- With each additional timestamp reinforcing the existence of the ones before it.



## POW (Proof of work)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pd7zwdouemlz4radce15.jpg)
- The proof-of-work involves scanning for a value that, when hashed (e.g., with SHA-256), the resulting hash begins with a number of zero bits. This specific value is known as the nonce
- The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.
- Proof-of-work is essentially a one-CPU-one-vote system.
- 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.
- To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour.
- If blocks are generated too fast, the difficulty (the number of zero bits) increases.


## Network


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3n6ghg8zlcqcpvjla4df.jpg)
- If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.
- In that case, they work on the first one they received but save the other branch in case it becomes longer.
- The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
- New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long.
- Some nodes may not receive blocks (e.g., due to network failure).
- If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.


## Incentive


- The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.
- The incentive can be new coins or transaction fees. Once a predetermined number of coins have entered circulation, the incentive is entirely transaction fees.


## Reclaiming Disk Space


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s482kocb5fbsi7sjcdvs.jpg)
- Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.


## Simplified payment verification

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vgz1bv3ggg4tc6umi4pi.jpg)
- It is possible to verify payments without running a full network node.
- A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.
- The user will have to see where the transaction is linked, and the more blocks are mined after it, the more the confirmation of the payment is reinforced.
- As long as the honest nodes control the network, it is reliable.


## Combining and Splitting Value


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j62tuvxgm41qirlua181.jpg)
- To make a transaction for every cent is inefficient.
- To allow value to be split and combined, transactions contain multiple inputs and outputs.
- Generally, there is a single input with a large previous transaction or multiple inputs with smaller previous transactions.
- At most, two outputs: one for payment, another for change (any extra amount after the costs, that must be returned to the payer).




## Privacy


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/03t6l18kk1rch43zwytn.jpg)
- A new key pair should be used for each transaction to keep them from being linked to a common owner.



---

- I am planning to write more posts on blockchain/Web3. <u>Follow</u> for more updates
- <u> Comment on any topic</u> you would like to see covered.
- I have tried to write in short bullet points, covering the main parts of the original text based on my learning and understanding. Please correct me if anything seems wrong.