Bitcoin 15 years, 43 million times

Bitcoin Celebrating 15 Years of Revolutionary Progress, with 43 Million Users and Counting

October 31, 2023, is the 15th anniversary of the release of the Bitcoin whitepaper.

On this day 15 years ago, Satoshi Nakamoto published the Bitcoin whitepaper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” on the P2P foundation website.

Around 6:15 PM on January 3, 2009, the genesis block of Bitcoin was generated in a small server in Helsinki, Netherlands, and it produced a block reward of 50 BTC, marking the official introduction of Bitcoin. The early trading price of Bitcoin was 0.0008 USD, but at the current price of 34,265.5 USD, its total market value reaches 664.8 billion USD, showing a more than 43 million-fold increase since its launch.

Bitcoin is a cryptocurrency that operates independently without the need for banking institutions and government intervention. It went through more than 20 years of technological evolution and failures in the field of cryptography before its introduction in 2008.

• 15 Years of Bitcoin: Unleashing the Crypto Revolution
• Botev Plovdiv FC Scores a Goal with Bitcoin Adoption
• Bitcoin’s Journey: Uptober Triumph and November Surprises

Carbon Link has summarized the timeline of Bitcoin’s birth as follows: On August 18, the Bitcoin.org domain was registered. On November 1, the whitepaper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” was released. On November 16, the pre-release version of Bitcoin v0.08 leaked.

On November 17, Satoshi Nakamoto wrote in an email to James A. Donald:

“I mean a node just needs to delay transactions (Pending-tx pool) to get the best branch it knows about, the best branch it can think of so far, and this branch will have the blocks and the tx pool the delayed tx pool needs. I think I’ve covered peer-to-peer broadcasting of timed block hashes with each node sending an inventory list containing new block hashes with transactions to its neighboring nodes.

The neighboring nodes will request items they don’t have. Items that time out should never make it through. They’ll request it again from other neighbor blocks that have it.

Since all or most neighboring blocks should have every item, even if it’s messed up by one block, they can get it from another block one at a time.

The inventory request scheme introduces some delay, but the request speed will eventually be improved because extra data blocks will be kept out of the transmitting queue, saving bandwidth as well.”

Over the past year and a half, I’ve been dealing with all these details and writing code, but there’s still a lot of work to be done. The whitepaper doesn’t cover all the functional details, but the source code will be released soon. I’ve sent you some of the main files (improvements can be made on request, the complete version will be released later).”

The term “Bitcoin miners” appeared in the version of Bitcoin distributed to Bitcointalk.org member “Cryddit.” This was the first time Satoshi Nakamoto referred to these network participants as “miners.” In the Bitcoin whitepaper, they were referred to as “nodes,” and the term “timechain” was initially used instead of “blockchain.”

In the blockchain, Satoshi Nakamoto left a sentence: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”

There’s no need to elaborate on the greatness of Bitcoin. Bitcoin has gone through a 15-year journey, experiencing various government regulations, community conflicts, and even being recognized as legal tender in El Salvador. Bitcoin is still Bitcoin. Time has proven everything.

On the important occasion of Bitcoin’s 15th anniversary, let’s review the content of the Bitcoin whitepaper published by Satoshi Nakamoto and relive the greatness of Bitcoin.

Bitcoin: A Peer-to-Peer Electronic Cash System

Original author: Satoshi Nakamoto Translator: Bitcoin Magazine

Abstract:

This paper proposes an electronic cash system that operates entirely through peer-to-peer technology, allowing online payments to be made directly from one party to another without the need for any financial institution. Although the use of digital signatures partially solves this problem, if third-party support is still required to prevent double-spending, then the value of such a system is lost. We propose a solution that allows the cash system to operate in a peer-to-peer environment and prevent double-spending. The network combines all transactions with timestamps using random hashing and incorporates them into an ever-growing chain of proof-of-work, which cannot be altered unless the entire proof-of-work is redone. The longest chain serves as both evidence of the observed sequence of events and is seen as coming from the pool with the highest CPU computational capacity. As long as the majority of CPU computational power does not intend to cooperate and attack the entire network, honest nodes will generate the longest chain that surpasses the attacker. This system requires minimal infrastructure. Information should be spread across the network to the best of its ability, and nodes can leave and rejoin the network at any time, using the longest proof-of-work chain as proof of transactions that occurred while the node was offline.

1. Introduction

Almost all trade on the internet requires the involvement of financial institutions as a reliable third party to process electronic payment information. Although these systems work well in most cases, they are inherently subject to the weaknesses of the trust-based model. People cannot achieve completely irreversible transactions because financial institutions inevitably intervene to resolve disputes. The existence of financial intermediaries also increases transaction costs and limits the minimum viable transaction size and daily small-value transactions. Furthermore, the potential loss lies in the fact that many goods and services are non-refundable. Without irreversible means of payment, internet trade is greatly limited. Because of the potential for refunds,

Trust is needed between the two parties involved in the transaction. In addition, because merchants must also be careful with their customers, they often ask for unnecessary personal information. In actual business transactions, a certain percentage of fraudulent customers are considered inevitable, and the resulting losses are treated as sales expenses. However, when using physical cash, these uncertainties in sales expenses and payment issues can be avoided because there is no third-party credit intermediary involved.

Therefore, we greatly need an electronic payment system that is based on cryptographic principles rather than credit, so that any two parties that reach an agreement can directly make payments without the need for a third-party intermediary. This eliminates the possibility of reversing payment transactions, protecting specific sellers from fraud. For those who want to protect buyers, setting up a typical third-party guarantee mechanism in this environment can be easy and enjoyable. In this paper, we will propose a peer-to-peer distributed timestamp server that generates electronically verified transaction proofs arranged and recorded in chronological order. This solves the double-spending problem. As long as the total computing power of honest nodes is greater than the total computing power of cooperating attackers, the system is secure.

2. Transactions

We define an electronic coin as a sequence of digital signatures: each owner signs a randomly hashed digital signature of the previous transaction and the public key of the next owner, and appends this signature to the end of the electronic coin before sending it to the next owner. The recipient can verify the ownership of the chain by verifying the signatures.

The problem with this process is that the recipient will have difficulty verifying whether a previous owner has double-spent the electronic coin. The typical solution is to introduce a trusted third-party authority or an institution similar to a mint to verify each transaction to prevent double-spending. After each transaction, the electronic coin is returned to the mint, and the mint issues a new electronic coin. Only electronic coins issued directly by the mint are considered valid, thus preventing double-spending. However, the problem with this solution is that the fate of the entire currency system depends entirely on the operation of the mint, as every transaction must go through the mint’s confirmation, making the mint comparable to a bank.

We need a method for the recipient to ensure that the previous owner has not signed a previous transaction. Logically, to achieve this, we only need to focus on the transactions that occurred before this transaction, without worrying about any attempts at double-spending after this transaction. To ensure the absence of a certain transaction, the only way is to know all previous transactions. In the mint model, the mint knows all the transactions and determines the order in which they are completed. If we want to eliminate third-party intermediaries in an electronic system, transaction information should be publicly announced. All participants in the system need to have a universally recognized historical transaction sequence. The recipient needs to ensure that during the transaction, the majority of nodes recognize that the transaction is occurring for the first time.

3. Timestamp Server

This solution first proposes a “timestamp server”. The timestamp server adds a timestamp to a set of data in the form of a block by implementing random hashes, and broadcasts the random hash, just like posting in news or Usenet. Obviously, the timestamp can prove that specific data existed at a certain moment, because the corresponding random hash value can only be obtained if it existed at that moment. Each timestamp should include the previous timestamp in its random hash value, and each subsequent timestamp reinforces the previous one, forming a chain.

1 W Dai, a scheme for a group of untraceable digital pseudonyms to transact with each other and enforce contracts without outside help, “B-money,” 1998

2 H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” at the 20th Symposium on Information Theory in the Benelux, May 1999

3 S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” in the Journal of Cryptology, vol. 3, No.2, pages 99-111, 1991

4 D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” in Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993

5 S. Haber, W.S. Stornetta, “Secure name for bit-strings,” in Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997

4. Proof-of-Work

In order to build a decentralized timestamp server based on peer-to-peer, simply working like a newspaper or global news network is not enough. We also need a mechanism similar to Adam Back’s Hashcash. When performing random hash calculations, the Proof-of-Work mechanism introduces scanning work for a specific value. For example, with SHA-256, the random hash value starts with one or more zeros. As the number of zeros increases, the workload required to find this solution exponentially grows, but the verification only requires one random hash calculation.

We add a random number (Nonce) to the block, which makes the random hash value of the given block have the desired number of zeros. We keep trying different random numbers until we find the right one. This way, we construct a Proof-of-Work mechanism. As long as the workload expended by the CPU satisfies the Proof-of-Work mechanism, the information in the block cannot be changed unless a considerable amount of work is redone. Since subsequent blocks are linked to this block, changing the information in this block would require redoing the entire workload of the subsequent blocks.

Meanwhile, the proof-of-work mechanism also solves the problem of who is the majority when voting collectively. If the way to determine the majority is based on IP addresses, one IP address, one vote, then if someone has the power to allocate a large number of IP addresses, the mechanism will be undermined. The essence of the proof-of-work mechanism is one CPU, one vote. The decision of the “majority” is expressed as the longest chain, because the longest chain contains the most work. If the majority of CPUs are controlled by honest nodes, then the honest chain will grow at the fastest rate and surpass other competing chains. If an attacker wants to modify a block that has already appeared, they must redo the work of that block plus the work of all subsequent blocks, and ultimately catch up with and surpass the work of honest nodes. We will prove later that if a slower attacker tries to catch up to subsequent blocks, the probability of their success will decrease exponentially.

Another problem is that the speed of hardware calculation is rapidly increasing, and the level of node participation in the network will fluctuate. To solve this problem, the difficulty of the proof-of-work will be determined by using a moving average target, which means setting the difficulty to achieve a certain predetermined average hourly block generation rate. If the block generation rate is too fast, the difficulty will increase.

5. Network

1) New transactions are broadcasted to the entire network;

2) Each node includes the received transaction information in a block;

3) Each node tries to find a proof-of-work with sufficient difficulty in its own block;

4) When a node finds a proof-of-work, it broadcasts it to the entire network;

5) Other nodes only recognize the validity of the block if all transactions contained in it are valid and have not existed before;

6) Other nodes indicate that they accept the block by creating new blocks at the end of the chain, thus extending the chain, and considering the random hash value of the accepted block as preceding the random hash value of the new block.

Nodes always consider the longest chain as the correct chain and continue to work on and extend it. If two nodes simultaneously broadcast different versions of a new block, other nodes will receive them at different times. In this case, they will work based on the block they receive first, but they will also keep the other chain in case it becomes the longest one. The stalemate will be broken when the next proof-of-work is found, and one of the chains is confirmed to be longer. Then, the nodes working on the alternative branch will switch and start working on the longer chain.

The so-called “broadcasting of new transactions” does not actually need to reach all nodes. As long as the transaction information can reach enough nodes, they will be quickly integrated into a block. And the broadcast of the block has fault-tolerance for discarded information. If a node does not receive a specific block, the node will discover that it is missing a block and can request to download that block.

6. Incentive

We agree that: the first transaction of each block is specially processed, and this transaction generates a new electronic currency owned by the creator of that block. This increases the incentive for nodes to support the network and, without a central authority issuing currency, provides a way to distribute electronic currency into circulation. This method of continuously adding a certain amount of new coins to the currency system is very similar to expending resources to mine gold and inject it into circulation. In this case, the consumption of CPU time and power is the consumed resource.

Another source of incentive is transaction fees. If the output value of a transaction is less than the input value, the difference is the transaction fee, which will be added to the incentive of that block. Once a certain amount of electronic currency has entered circulation, the incentive mechanism can gradually transition to relying entirely on transaction fees, allowing the currency system to be free from inflation.

The incentive system also helps encourage nodes to remain honest. If a greedy attacker is able to mobilize more CPU computing power than all honest nodes combined, he faces a choice: either use it for honest work to generate new electronic currency, or use it for double-spending attacks. Then he will find that it is more profitable to act according to the rules and work honestly. Because these rules allow him to have more electronic currency, rather than destroy the validity of his own wealth by breaking the system.

7. Reclaiming Hard Drive Space

If recent transactions have been included in enough blocks, the data before those transactions can be discarded in order to reclaim hard drive space. In order to ensure that the random hash value of the blocks is not compromised, when the transaction information is randomly hashed, it is built into a Merkle tree form, so that only the root is included in the random hash value of the block. Old blocks can be compressed by stubbing the branches of this tree, and the internal random hash values do not need to be saved.

A block header without transaction information is only 80 bytes in size. If we set the block generation rate to one every 10 minutes, then the data generated in one year is 4.2MB. (80 bytes * 6 * 24 * 365 = 4.2MB). In 2008, the typical memory capacity of a PC system was 2GB, and according to Moore’s Law, even storing all block headers in memory is not a problem.

8. Simplified Payment Verification (SPV)

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers with the longest proof-of-work chain, which it can continually query the network for until it is convinced it has the longest chain and can link the transaction to the time it was accepted into a block by linking it to a branch in the merkle tree. While the process of verifying the transaction itself cannot be done by the user, by going back through the chain, it can see that a network node has accepted it and further confirmations by subsequent blocks prove that the entire network accepted it.

In this scenario, as long as honest nodes control the network, the verification mechanism is reliable. However, when the network is attacked by a powerful attacker with majority control, it becomes more vulnerable. Because network nodes can individually verify the validity of transactions, as long as the attacker can maintain a majority of the computational power, the simplified mechanism can be deceived by fabricated transactions made by the attacker. Therefore, a feasible strategy is for nodes to immediately raise alarm when they discover an invalid block. Users who receive the alert can then download the complete information of the block or transaction that raised the alarm in order to judge the inconsistency of the information. For businesses that conduct a large volume of transactions, they may still prefer to run their own full nodes to maintain greater independence, integrity, and verification speed.

9. Combining and Splitting Value

While it is possible to individually handle electronic currencies, initiating a separate transaction for each electronic coin would be cumbersome. To make value combinations and divisions easier, transactions are designed to include multiple inputs and outputs. Typically, a single input is made up of a previous transaction with a higher value, or parallel inputs composed of several previous transactions with lower values. However, there can be a maximum of only two outputs: one for payment and, if applicable, one for change.

It should be noted that although a transaction depends on previous transactions, and those transactions in turn depend on multiple transactions, there is no problem with this mechanism. This working mechanism does not require a verification of the entire transaction history that occurred prior to it.

10. Privacy

The traditional minting model provides a certain level of privacy protection for transaction participants, as attempting to obtain transaction information from a trusted third party is strictly limited. However, if transaction information is broadcasted to the entire network, this method becomes ineffective. But privacy can still be protected by keeping the public key anonymous. The information known to the public is only that someone sent a certain amount of currency to another person, but it is difficult to link the transaction to a specific individual. In other words, the public cannot be certain of the identities of those involved. This is similar to the information disclosed by stock exchanges, where the time and volume of each stock transaction are recorded and available for inquiry, but the identities of the parties involved are not revealed.

As an additional precaution, users can generate a new address for each transaction to ensure that these transactions cannot be traced back to a common owner. However, due to parallel inputs, some degree of tracing is still inevitable, as parallel inputs imply that these coins belong to the same owner. The risk here is that if someone’s public key is confirmed to belong to them, then many other transactions of this person can be traced.

11. Calculation

Imagine the following scenario: an attacker tries to generate an alternative blockchain faster than honest nodes. Even if they succeed, the entire system is not completely at the mercy of the attacker’s will, such as creating value out of thin air or seizing currency that does not belong to the attacker. This is because nodes will not accept invalid transactions, and honest nodes will never accept a block containing invalid information. The most an attacker can do is change their own transaction information and attempt to take back the money they just paid to someone else.

The race between the honest chain and the attacker chain can be described using a binomial random walk. A successful event is defined as the honest chain extending by one block, increasing its lead by +1, while a failed event is the attacker’s chain extending by one block, decreasing the gap by -1.

The possibility of an attacker successfully filling a given gap can be approximated as the gambler’s ruin problem. Assuming a gambler has unlimited overdraft credit and starts an infinite number of potential gambling attempts in an effort to fill their deficit. We can then calculate the probability of them filling the deficit, which is equivalent to the attacker catching up with the honest chain, as shown below:

Assuming p > q, the probability of a successful attack decreases exponentially with the growth of the number of blocks. Since probability is the enemy of the attacker, if they cannot achieve success quickly and luckily, their chances of success become increasingly slim over time. So, we consider how long a recipient needs to wait to be reasonably certain that the sender is unable to change the transaction. We assume the sender is a double-spending attacker who wants the recipient to believe they have been paid for a certain period of time and then immediately redirect the payment back to themselves. Although the recipient will eventually realize this, it will be too late.

The recipient generates a new key pair and only keeps the public key reserved for a short period of time to send it to the sender. This prevents the following scenario: the sender prepares a blockchain in advance and continuously performs calculations on it until their blockchain luckily surpasses the honest chain, at which point they execute the payment immediately. In this case, as soon as the transaction is sent, the attacker secretly starts preparing a parallel chain that includes an alternative version of that transaction.

Then the recipient will wait for the transaction to appear in the first block, and then wait for z blocks to be linked afterwards. At this point, he still can’t know exactly how many blocks the attacker has progressed, but assuming honest blocks take an average expected time to generate a block, then the potential progress of the attacker is a Poisson distribution with an expected value of:

In this case, to calculate the probability of the attacker catching up, we take the probability density of the Poisson distribution of the number of blocks the attacker has made progress on, multiplied by the probability that the attacker can still catch up at that number.

It can be transformed into the following form, avoiding the sum of an infinite series:

Written as the following C language code:

By performing the calculations, we can obtain the following probability results, which show an exponential decrease with increasing z value.

12. Conclusion

We have proposed an electronic payment system that does not require a trusted intermediary. We first discuss the principles of electronic signatures in traditional electronic currencies. Although this system provides strong control over ownership, it is not sufficient to prevent double-spending. To solve this problem, we propose a peer-to-peer network using a proof-of-work mechanism to record the public information of transactions. As long as honest nodes control the majority of CPU computing power, it will be difficult for attackers to change transaction records.

The strength of this network lies in its structural simplicity. The work between nodes is mostly independent, requiring only minimal coordination. Each node does not need to explicitly identify itself, and since there are no requirements for the flow path of transaction information, it only needs to make every effort to propagate. Nodes can leave the network at any time, and it is also very easy to rejoin the network by simply supplementing the proof-of-work chain during the period of absence.

Nodes vote through their own CPU computing power to confirm valid blocks, constantly extending the valid blockchain to express their confirmation and refusing to extend the blocks after invalid blocks to signify rejection. This framework includes all the rules and incentives needed for a P2P electronic currency system.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!