Most people only know that Nakamoto has created Bitcoin, but his posts are little known.

Original: Five fireball masters

Every time I talk about BTC, BCH, and BSV, many people will dismiss the latter two. The reason is: What is the name of Bitcoin for the fork coin ?

Others questioned that the ship of Theseus was repaired and repaired. After every piece of wood on the ship was replaced, was the ship still the ship at the time of departure? BTC was modified a little after Core took over , or was it BTC that Nakamoto had envisioned?

Today, let's put aside the three-word conception and just say the word "bitcoin".

• The history of the rise and fall of the exchange: an important silhouette of the development of blockchain
• Xinhua News Agency: In the blockchain "new track", Shenzhen is committed to becoming the high ground of the blockchain global industrial chain technology chain
• The regulatory high pressure continues and the market needs to return to rationality

Surprisingly, the vast majority of investors, even the “believers” who include many bitcoins, have not read the Bitcoin white paper, not to mention the posts that Nakamoto had published on the Bitcointalk forum earlier. As a result, many people have made many mistakes or deviations from Bitcoin or Nakamoto. For example, many articles on the Internet mentioned that “Zhong Bencong did not expect the birth of ASIC mining machine ”.

Of course, Nakamoto's initial design has many mistakes and needs to be revised by future generations. But in any case, we must at least know what Nakamoto was thinking at first.

The core part of Nakamoto's vision is in the Bitcoin white paper. This article focuses on his early speech on the Bitcointalk forum.

01 full node problem

This may be the root cause of BTC and BCH, BSV separation, the larger block is more of a representation, and the deeper is the question of who can run the whole node.

The general meaning of the post is as follows:

“The current system where each user is a network node is not a standard after scale-up, just as every Usenet user runs his own NNTP server. This design supports the user as a user, and the more burden of running the node. The fewer nodes there are. The final nodes will be large server clusters, and the rest will be client nodes that only execute transactions without generating them."

Then, below the post, someone asked (this person is the current EOS Creation BM ): "Cong Ge, you have verified that the payment is too long for ten minutes? This stuff is as fast as swiping a credit card today!"

Cong Brother replied bitterly: Going to see my "snack machine" sticker, I outlined how the payment processor can be good enough in 10 seconds or less, actually very good (much lower than the credit card) The fraud rate) verifies the payment. ("Snack machine" posted below we will talk about)

"If you don't believe me or can't understand, brother doesn't have time to convince you, sorry."

Later, BM returned a post, saying "practice":

In fact, I totally believe in you, and after reading your post, I also came to the same conclusion as you. I went to see the post about Snackmachine after the previous reply.

02 ASIC Mining Machine and SPV

This is actually a continuation of the previous problem. Nakamoto can be said to have designed or promoted the concept of ASIC, but did not expect the emergence of such an extreme ASIC.

Post meaning:

This design outlines a light client that does not require a full blockchain, which is called simplified payment verification. Light clients can send and receive transactions, but they can't block. It does not require a trusted node to verify the payment, it can still verify the payment itself. The light client has not been implemented, but the plan is to implement it when needed.

Now everyone runs only one complete network node. I don't expect more than 100,000 nodes, maybe less. It will reach a balance where more nodes cannot join. The rest will be light clients, which may be millions. At a balanced size, many nodes will be server clusters, with one or two primary nodes connected to other servers over the LAN.

Therefore, Nakamoto did not expect the birth of ASIC, and it is not right.

Strictly speaking, this kind of top ASIC implementation of thousands of PCs or servers, Sakamoto did not expect. But this kind of power cluster, which is more efficient than CPU or GPU, is thought of and described by Nakamoto. Its core concept is essentially the same as the current ASIC pools.

Regarding SPV , Nakamoto also sent a post with the following meaning:

Not only downloading, but it also takes a long time to verify all signatures in all blocks. How long does it usually take to download the initial block? Is it slowing down in the second half or is it almost the same speed? I've thought about a simpler and more rude way of checking the chain. I can check the last few thousand blocks, but it's very time consuming, and there are many other more important things that I need to deal with.

Simplified payment verification is suitable for lightweight client-only users who only trade and do not participate in or participate in the node network. They do not need to download the block, just download the hash chain, the hash chain is currently about 2MB, and the verification speed is very fast. Fast (verify the entire chain for less than a second). If the network becomes very large (for example, more than 100,000 nodes), this is the case we will use to allow ordinary users to trade without having to become a full node. At that stage, most users should start running only the SPV client software, and only professional server pools can continue to run full network nodes, just as the Usenet network integrates.

SPV has not been implemented and will not be implemented in the short term, but all current implementations are designed around supporting SPV.

Part 8 of the Bitcoin White Paper is an introduction to SPV, and interested friends can turn the white paper on their own.

Simply put, SPV is a technical means for users to verify payment without running a full node. Users only need to save all the block headers. Although the user can't verify the transaction by himself, if he can find a matching transaction from somewhere in the blockchain, he knows that the network has approved the transaction, and how many confirmations of the network are obtained. The SPV is doing "payment verification". Only judge whether the transaction used for "payment" has been verified, and how much power protection (how many block confirmations) is obtained, instead of the "transaction verification" of the whole node (related to whether the verification is sufficient The balance is available for spending, whether there is a double flower, whether the script can pass, etc.).

At present, most of the bitcoin "light wallets" on the market draw on the idea of ​​SPV, but it is not a true SPV wallet, but more like a front end of a blockchain browser plus a private key to sign. The function, which cannot be verified by itself, needs to connect to other full nodes, instead of decentralized independent verification like SPV.

BTC insists that individual users can run full nodes, so there is a high probability that SPV will not be developed, but for BCH and BSV, SPV is an extremely important technology, so I believe that the mature SPV wallet will be seen in the near future. Appearance.

03 “Snack Machine”

This is a question about how Bitcoin is confirmed in a very short period of time . It is not 100% fully confirmed and the transaction is irreversible, but "good enough" to be better than the credit card failure rate.

The "snack machine" originated from a person's post, saying that if there is a bitcoin version of the snack machine (unmanned vending machine), how would it work? No one wants to spend an hour waiting for the transaction to be confirmed, and the “snack machine” company does not want to give so many free snacks.

Cong Ge replied:

I believe that payment processing companies can provide fast transaction publishing services through "good enough" checks in 10 seconds or less.

The network node only accepts the first version of the recommendation to merge it into the block they are trying to generate. When you broadcast a transaction, if someone else broadcasts a double flower at the same time, this becomes a speed race where the competition spreads to the most nodes. As long as one party is slightly ahead, it will spread faster and faster on the network and be recognized by most nodes.

A rough example: 1 0 4 1 16 4 64 16 80% 20%

Therefore, even if the double flower has to wait for one second, it will occupy a huge disadvantage.

The payment processor is connected to many nodes. When it gets a deal, it sends it out quickly, monitoring whether there are double flowers in the network. If it receives a double flower on any of its many nodes, it will warn that the transaction is wrong…. The double flower transaction will not spread far. The double flowerer will have to wait until the listening phase is over. But by then, the payment processor's broadcast has reached most of the nodes, or is far ahead in terms of propagation, so that the double-flowerer has little hope of preempting most of the remaining nodes.

Zero confirmation is also a lot of research on BCH and BSV, and there is still not a lot of merchant support. Although zero confirmation is technically plausible, in most people's minds, transactions are always unsafe if they are not confirmed. BTC is basically not likely to take this technical route. After all, zero-acknowledgment and lightning network are not a single path.

04
The future of Bitcoin: What is it like 20 years from now?

Regarding the future of Bitcoin, Nakamoto has given his ideas in several posts. The following are only excerpts:

The nature of Bitcoin is such that once the 0.1 release is released, the core design is static throughout its lifecycle. Therefore, I want to design it to support every possible type of transaction I can think of. The problem is that everything needs special support code and data fields, whether or not they are used, and only one special case is involved at a time. This will be a special case of explosion, the solution is a script…

The payment recipient performs template matching on the script. Currently, the recipient only accepts two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types, and nodes running this version or later will be able to receive them…

This design supports the various types of transactions I have designed many years ago: managed transactions, bonded contracts, third-party arbitration, multi-party signing, and more. If Bitcoin floods in, these are things we will explore in the future, but they must all be designed at the outset to be usable in the future.

I believe that most people are no strangers to this sentence: after a few decades, when the block rewards almost disappear, the transaction fee will be the main source of income for the node. I am very convinced that after 20 years, the number of transactions on the chain is either very large or not.

From the perspective of Nakamoto's vision, whether it is a custody transaction, the support of a bonded contract, or the assumption of the number of transactions on the chain, it may be related to the current BTC's style of “ electronic gold stored value + lightning network ”.

Of course, as stated at the beginning of the article, Nakamoto’s idea is still wrong. This is a matter of opinion. The more significance of this article is to show some of Nakamoto's ideas in the past, support and otherwise rely on personal understanding.

After all, the Ethereum that V God first envisioned was a world computer. As a result, the machine that developed Token was inadvertently developed. Now it has become the DeFi settlement layer, and the dream of the world computer has long since deviated.

The EOS that BM originally envisioned was the enterprise operating system (the full name of EOS), and the result is now a "spinach" chain. What will become the next step is not known.

Therefore, from this point of view, BTC is indeed not electronic gold in the eyes of Satoshi Satoshi, but it has become a "electronic gold" inexplicably.

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