vgsantoniazzi / blockchain Goto Github PK

From bitcoin paper

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts.

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.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the
block until a value is found that gives the block's hash the required zero bits. Once the CPU
effort has been expended to make it satisfy the proof-of-work, the block cannot be changed
without redoing the work. As later blocks are chained after it, the work to change the block
would include redoing all the blocks after it.

The proof-of-work also solves the problem of determining representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the greatest proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the
fastest and outpace any competing chains. 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. We will show later that the probability of a slower attacker catching up
diminishes exponentially as subsequent blocks are added.

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 they're generated too fast, the difficulty increases.

To check proof-of work, we need to expose (as an API) the entire blockchain to let other computers download it.

Golang is nice, but I think that should we do in elixir, as we have awesome sync features there, seems a nice path to follow.

Based on Hashcash

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space. To facilitate this without breaking the block's hash,
transactions are hashed in a Merkle Tree, with only the root included in the block's hash.
Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.
A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.

https://elixir-lang.org/getting-started/mix-otp/distributed-tasks.html

In the Bitcoin white paper [1], Nakamoto proposed a very simple Byzantine fault tolerant consensus algorithm
that is also known as Nakamoto consensus. Despite its simplicity, some existing analysis of Nakamoto consensus
appears to be long and involved. In this technical report, we aim to make such analysis simple and transparent
so that we can teach senior undergraduate students and graduate students in our institutions. This report is largely
based on a 3-hour tutorial given by one of the authors in June 2019 [2].

From https://arxiv.org/pdf/1910.08510.pdf

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 proofof-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.