Bitcoin: A Peer-to-Peer Electronic Cash System
When trying to understand what Bitcoin is and does, it's helpful to start with an understanding of the context in which it was build and the problem it was trying to solve. There were many digital currencies before Bitcoin, but Bitcoin was the first decentralized digital currency. Creating a digital currency without a central authority was the problem that was being solved for.
Bitcoin was first introduced to the world On October 31, 2008, with the publishing of the Bitcoin white paper Bitcoin: A Peer-to-Peer Electronic Cash System. The paper gives insight into the motivations and architecture of the system. Much of what is covered in the paper are topics that we will dive into in later units. So, we recommend reading through it briefly now and coming back to it often throughout your studies.
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on extending it. 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. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.