Bitcoin

A Peer-to-Peer Electronic Cash System

Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through
a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-
spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into
an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only
serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is
controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires
minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work
chain as proof of what happened while they were gone.

1. Introduction p = probability an honest node finds the next block

8. Simplified Payment Verification q = probability the attacker finds the next block
Commerce on the Internet has come to rely almost exclusively It is possible to verify payments without running a full qz = probability the attacker will ever catch up from z blocks behind
on financial institutions serving as trusted third parties to network node. A user only needs to keep a copy of the block
process electronic payments. While the system works well headers of the longest proof-of-work chain, which he can get
enough for most transactions, it still suffers from the inherent The proof-of-work also solves the problem of determining
by querying network nodes until he's convinced he has the
weaknesses of the trust based model. Completely non- representation in majority decision making. If the majority
longest chain, and obtain the Merkle branch linking the Given our assumption that p > q, the probability drops
reversible transactions are not really possible, since financial were based on one-IP-address-one-vote, it could be
transaction to the block it's timestamped in. He can't check exponentially as the number of blocks the attacker has to
institutions cannot avoid mediating disputes. The cost of subverted by anyone able to allocate many IPs. Proof-of-work
the transaction for himself, but by linking it to a place in the catch up with increases. With the odds against him, if he
mediation increases transaction costs, limiting the minimum is essentially one-CPU-one-vote. The majority decision is
chain, he can see that a network node has accepted it, and doesn't make a lucky lunge forward early on, his chances
practical transaction size and cutting off the possibility for represented by the longest chain, which has the greatest
blocks added after it further confirm the network has become vanishingly small as he falls further behind.
small casual transactions, and there is a broader cost in the proof-of-work effort invested in it. If a majority of CPU power
accepted it. We now consider how long the recipient of a new
loss of ability to make non-reversible payments for non- is controlled by honest nodes, the honest chain will grow the
transaction needs to wait before being sufficiently certain the
reversible services. With the possibility of reversal, the need fastest and outpace any competing chains. To modify a past
sender can't change the transaction. We assume the sender is
for trust spreads. Merchants must be wary of their customers, block, an attacker would have to redo the proof-of-work of
an attacker who wants to make the recipient believe he paid
hassling them for more information than they would the block and all blocks after it and then catch up with and
him for a while, then switch it to pay back to himself after
otherwise need. A certain percentage of fraud is accepted as surpass the work of the honest nodes. We will show later that
some time has passed. The receiver will be alerted when that
unavoidable. These costs and payment uncertainties can be the probability of a slower attacker catching up diminishes
happens, but the sender hopes it will be too late.
avoided in person by using physical currency, but no exponentially as subsequent blocks are added.
The receiver generates a new key pair and gives the public
mechanism exists to make payments over a communications To compensate for increasing hardware speed and varying
key to the sender shortly before signing. This prevents the
channel without a trusted party. interest in running nodes over time, the proof-of-work
sender from preparing a chain of blocks ahead of time by
What is needed is an electronic payment system based on difficulty is determined by a moving average targeting an
working on it continuously until he is lucky enough to get far
cryptographic proof instead of trust, allowing any two willing average number of blocks per hour. If they're generated too
As such, the verification is reliable as long as honest nodes enough ahead, then executing the transaction at that
parties to transact directly with each other without the need fast, the difficulty increases.
control the network, but is more vulnerable if the network is moment. Once the transaction is sent, the dishonest sender
for a trusted third party. Transactions that are overpowered by an attacker. While network nodes can verify starts working in secret on a parallel chain containing an
computationally impractical to reverse would protect sellers 5. Network transactions for themselves, the simplified method can be alternate version of his transaction.
from fraud, and routine escrow mechanisms could easily be The steps to run the network are as follows: fooled by an attacker's fabricated transactions for as long as The recipient waits until the transaction has been added to
implemented to protect buyers. In this paper, we propose a 1) New transactions are broadcast to all nodes. the attacker can continue to overpower the network. One a block and z blocks have been linked after it. He doesn't
solution to the double-spending problem using a peer-to-peer 2) Each node collects new transactions into a block. strategy to protect against this would be to accept alerts from know the exact amount of progress the attacker has made,
distributed timestamp server to generate computational 3) Each node works on finding a difficult proof-of-work for network nodes when they detect an invalid block, prompting but assuming the honest blocks took the average expected
proof of the chronological order of transactions. The system is its block. the user's software to download the full block and alerted time per block, the attacker's potential progress will be a
secure as long as honest nodes collectively control more CPU 4) When a node finds a proof-of-work, it broadcasts the transactions to confirm the inconsistency. Businesses that Poisson distribution with expected value:
power than any cooperating group of attacker nodes. block to all nodes. receive frequent payments will probably still want to run their
5) Nodes accept the block only if all transactions in it are own nodes for more independent security and quicker
2. Transactions valid and not already spent. verification. To get the probability the attacker could still catch up now,
We define an electronic coin as a chain of digital signatures. 6) Nodes express their acceptance of the block by working we multiply the Poisson density for each amount of progress
on creating the next block in the chain, using the hash of
Each owner transfers the coin to the next by digitally signing 9. Combining and Splitting Value he could have made by the probability he could catch up from
a hash of the previous transaction and the public key of the the accepted block as the previous hash. that point:
Although it would be possible to handle coins individually, it
next owner and adding these to the end of the coin. A payee Nodes always consider the longest chain to be the correct one
would be unwieldy to make a separate transaction for every
can verify the signatures to verify the chain of ownership. and will keep working on extending it. If two nodes broadcast
cent in a transfer. To allow value to be split and combined,
different versions of the next block simultaneously, some
transactions contain multiple inputs and outputs. Normally
nodes may receive one or the other first. In that case, they Rearranging to avoid summing the infinite tail of the
there will be either a single input from a larger previous
work on the first one they received, but save the other branch distribution...
transaction or multiple inputs combining smaller amounts,
in case it becomes longer. The tie will be broken when the
and at most two outputs: one for the payment, and one
next proof- of-work is found and one branch becomes longer;
returning the change, if any, back to the sender.
the nodes that were working on the other branch will then
switch to the longer one. Converting to C code...
New transaction broadcasts do not necessarily need to
#include <math.h>
reach all nodes. As long as they reach many nodes, they will
double AttackerSuccessProbability(double q, int z) {
get into a block before long. Block broadcasts are also tolerant double p = 1.0 - q;
double lambda = z * (q / p);
of dropped messages. If a node does not receive a block, it
It should be noted that fan-out, where a transaction double sum = 1.0;

The problem of course is the payee can't verify that one of the will request it when it receives the next block and realizes it int i, k;
depends on several transactions, and those transactions
owners did not double-spend the coin. A common solution is missed one. for (k = 0; k <= z; k++) {
depend on many more, is not a problem here. There is never double poisson = exp(-lambda);
to introduce a trusted central authority, or mint, that checks the need to extract a complete standalone copy of a for (i = 1; i <= k; i++)
every transaction for double spending. After each 6. Incentive transaction's history. poisson *= lambda / i;

transaction, the coin must be returned to the mint to issue a By convention, the first transaction in a block is a special sum -= poisson * (1 - pow(q / p, z - k));
}
new coin, and only coins issued directly from the mint are transaction that starts a new coin owned by the creator of the
10. Privacy
trusted not to be double-spent. The problem with this block. This adds an incentive for nodes to support the return sum;
The traditional banking model achieves a level of privacy by }
solution is that the fate of the entire money system depends network, and provides a way to initially distribute coins into
limiting access to information to the parties involved and the
on the company running the mint, with every transaction circulation, since there is no central authority to issue them. Running some results, we can see the probability drop off
trusted third party. The necessity to announce all transactions
having to go through them, just like a bank. The steady addition of a constant of amount of new coins is exponentially with z.
publicly precludes this method, but privacy can still be
We need a way for the payee to know that the previous analogous to gold miners expending resources to add gold to q=0.1 q=0.3
maintained by breaking the flow of information in another z=0 P=1.0000000 z=0 P=1.0000000
owners did not sign any earlier transactions. For our circulation. In our case, it is CPU time and electricity that is z=1 P=0.2045873 z=5 P=0.1773523
place: by keeping public keys anonymous. The public can see
purposes, the earliest transaction is the one that counts, so expended. z=2 P=0.0509779 z=10 P=0.0416605
that someone is sending an amount to someone else, but z=3 P=0.0131722 z=15 P=0.0101008
we don't care about later attempts to double-spend. The only The incentive can also be funded with transaction fees. If z=4 P=0.0034552 z=20 P=0.0024804
without information linking the transaction to anyone. This is z=5 P=0.0009137 z=25 P=0.0006132
way to confirm the absence of a transaction is to be aware of the output value of a transaction is less than its input value, z=6 P=0.0002428 z=30 P=0.0001522
similar to the level of information released by stock z=7 P=0.0000647 z=35 P=0.0000379
all transactions. In the mint based model, the mint was aware the difference is a transaction fee that is added to the z=8 P=0.0000173 z=40 P=0.0000095
exchanges, where the time and size of individual trades, the
of all transactions and decided which arrived first. To incentive value of the block containing the transaction. Once z=9 P=0.0000046 z=45 P=0.0000024
"tape", is made public, but without telling who the parties z=10 P=0.0000012 z=50 P=0.0000006
accomplish this without a trusted party, transactions must be a predetermined number of coins have entered circulation,
were.
publicly announced [1], and we need a system for participants the incentive can transition entirely to transaction fees and be Solving for P less than 0.1%...
to agree on a single history of the order in which they were completely inflation free. P < 0.001 q=0.30 z=24
q=0.10 z=5 q=0.35 z=41
received. The payee needs proof that at the time of each The incentive may help encourage nodes to stay honest. If a q=0.15 z=8 q=0.40 z=89
q=0.20 z=11 q=0.45 z=340
transaction, the majority of nodes agreed it was the first greedy attacker is able to assemble more CPU power than all q=0.25 z=15
received. 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. He ought to find it more profitable to
12. Conclusion
3. Timestamp Server As an additional firewall, a new key pair should be used for We have proposed a system for electronic transactions
The solution we propose begins with a timestamp server. A play by the rules, such rules that favour him with more new
each transaction to keep them from being linked to a without relying on trust. We started with the usual framework
timestamp server works by taking a hash of a block of items coins than everyone else combined, than to undermine the
common owner. Some linking is still unavoidable with multi- of coins made from digital signatures, which provides strong
to be timestamped and widely publishing the hash, such as in system and the validity of his own wealth.
input transactions, which necessarily reveal that their inputs control of ownership, but is incomplete without a way to
a newspaper or Usenet post [2-5]. The timestamp proves that were owned by the same owner. The risk is that if the owner prevent double-spending. To solve this, we proposed a peer-
the data must have existed at the time, obviously, in order to 7. Reclaiming Disk Space of a key is revealed, linking could reveal other transactions to-peer network using proof-of-work to record a public
get into the hash. Each timestamp includes the previous Once the latest transaction in a coin is buried under enough that belonged to the same owner. history of transactions that quickly becomes computationally
timestamp in its hash, forming a chain, with each additional blocks, the spent transactions before it can be discarded to impractical for an attacker to change if honest nodes control a
timestamp reinforcing the ones before it. save disk space. To facilitate this without breaking the block's
11. Calculations majority of CPU power. The network is robust in its
hash, transactions are hashed in a Merkle Tree [7][2][5], with unstructured simplicity. Nodes work all at once with little
We consider the scenario of an attacker trying to generate an
only the root included in the block's hash. Old blocks can then coordination. They do not need to be identified, since
alternate chain faster than the honest chain. Even if this is
be compacted by stubbing off branches of the tree. The messages are not routed to any particular place and only
accomplished, it does not throw the system open to arbitrary
interior hashes do not need to be stored. need to be delivered on a best effort basis. Nodes can leave
changes, such as creating value out of thin air or taking
money that never belonged to the attacker. Nodes are not and rejoin the network at will, accepting the proof-of-work
4. Proof-of-Work going to accept an invalid transaction as payment, and honest chain as proof of what happened while they were gone. They
To implement a distributed timestamp server on a peer-to- nodes will never accept a block containing them. An attacker vote with their CPU power, expressing their acceptance of
peer basis, we will need to use a proof- of-work system similar can only try to change one of his own transactions to take valid blocks by working on extending them and rejecting
to Adam Back's Hashcash [6], rather than newspaper or back money he recently spent. invalid blocks by refusing to work on them. Any needed rules
Usenet posts. The proof-of-work involves scanning for a value The race between the honest chain and an attacker chain and incentives can be enforced with this consensus
that when hashed, such as with SHA-256, the hash begins can be characterized as a Binomial Random Walk. The success mechanism.
with a number of zero bits. The average work required is event is the honest chain being extended by one block, References
exponential in the number of zero bits required and can be increasing its lead by +1, and the failure event is the attacker's [1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.
verified by executing a single hash. chain being extended by one block, reducing the gap by -1. [2] Massias, et al., "Design of a secure timestamping service with minimal trust requirements,"
In 20th Symposium on Information Theory in the Benelux, May 1999.
For our timestamp network, we implement the proof-of- A block header with no transactions would be about 80 bytes.
The probability of an attacker catching up from a given [3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology,
work by incrementing a nonce in the block until a value is If we suppose blocks are generated every 10 minutes, 80 vol 3, no 2, pages 99-111, 1991.
deficit is analogous to a Gambler's Ruin problem. Suppose a [4] Bayer et al., "Improving the efficiency and reliability of digital time-stamping," In Sequences
found that gives the block's hash the required zero bits. Once bytes * 6 * 24 * 365 = 4.2MB per year. With computer
gambler with unlimited credit starts at a deficit and plays II: Methods in Comm., Security and Computer Science, p. 329-334, 1993.
the CPU effort has been expended to make it satisfy the systems typically selling with 2GB of RAM as of 2008, and [5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM
potentially an infinite number of trials to try to reach Conference on Computer and Communications Security, pages 28-35, April 1997.
proof-of-work, the block cannot be changed without redoing Moore's Law predicting current growth of 1.2GB per year, [6] A. Back, "Hashcash - a denial of service counter-measure,"
breakeven. We can calculate the probability he ever reaches
the work. As later blocks are chained after it, the work to storage should not be a problem even if the block headers http://www.hashcash.org/papers/hashcash.pdf, 2002.
breakeven, or that an attacker ever catches up with the [7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security
change the block would include redoing all the blocks after it. must be kept in memory. and Privacy, IEEE Computer Society, pages 122-133, April 1980.
honest chain, as follows [8]: [8] W. Feller, "An introduction to probability theory and its applications," 1957.

✅ Download High-Resolution PDF: https://blog.finxter.com/bitcoin-whitepaper-poster