Getting started with blockchain | Have you seen the first reference to Nakamoto's white paper?

The first reference of Nakamoto's white paper: The URL points to an article, I simply translated, interested to read the original text: http://www.weidai.com/bmoney.txt

text:

I am fascinated by Tim May's encrypted unregulated community. Unlike the “unregulated community” in the traditional sense of the community, regulation is not temporarily destroyed in an encrypted unregulated community, but is permanently prohibited and permanently unnecessary. This will be a community without threats of violence, because violence is impossible, and the reason why violence is impossible is because participants in community affairs cannot know the real name and actual geographical location of the other party.

So far, even in theory, it is not clear how to implement such a community. The community is determined by people with the same consensus. Efficient consensus requires a value exchange medium ( money) and a method of enforcing contracts . In the past, these services were provided by entities controlled by community core teams or community core teams. In this article, I will describe an agreement that makes provisioning and receiving services completely untrackable.

I actually described two protocols. The first one is impractical because it makes extensive use of synchronous and non-adjustable anonymous broadcast channels. However, it will motivate the second agreement, a more practical one. In both cases, I assume that there is a network that cannot be tracked, where the sender and receiver only pass the numeric id (like the public key), each message is signed by its sender and encrypted and sent to the recipient. .

• Facebook purchased the trademark Libra for the blockchain project, originally held by the encryption tax company
• Ma Yun's Stabilization Coin Plan: Ant's "Points" Token Plan?
• Talk | Stabilizing coins printing story

In the first agreement, each participant maintains a (standalone) database that records how much each id has. All of these accounts define the ownership of all currencies, and how to update these account balances is the main content of the agreement.

1. Create money.

Anyone can create money by broadcasting an answer to a previously unresolved computing problem. The only condition is that the amount of computation to solve the problem must be easily determined.

In addition, the answer must be worthless, both for practical use and for theoretical purposes. The number of monetary units is equal to the cost of the calculation work, and the calculation cost is based on a basket of standard commodity conversions. For example, if the computational problem requires 100 hours of computer computing under the most economical conditions, the current open market, 100 hours of computing power is equivalent to three standard purchasing powers, and then because the computing problem solution is broadcast, each Individuals add the broadcaster's account to three units.

2. Transfer funds.

If Alice (number id is K_A) wants to send X units of money to Bob (the number id is K_B), K_A signs and broadcasts the message "I provide X unit amount to K_B". Upon receipt of this message, each person deducts X units from K_A's account and K_B's account by X units. If the K_A balance is insufficient, the transaction information is invalid.

3. The impact of the contract.

Efficient contracts must include complete compensation because each party is likely to default. It also includes a third party, and when it is controversial, it is decided by a third party. All parties to the contract, including the arbitrator, must sign the broadcast of the transaction information before the transaction becomes valid.

By broadcasting the contract and all the signature information, each participant takes a part of the money from his account and transfers it to a special account id, which is the encrypted hash generation of the contract, and the digital id account is used to ensure the smooth execution of the contract, if each The balance of the participants is sufficient and the contract is effective, otherwise the contract is ignored and the account balance is rolled back.

Example: K_A agrees to send the solution of question P to K_B before 0:0:0 1/1/2000. K_B agrees to pay K_A 100 MU (currency unit) before 0:0:0 1/1/2000. K_C agrees to arbitrate in disputed circumstances. K_A agreed to pay for 1000 MU. K_B agrees to pay up to 200 MU. K_C agreed to pay 500MU.

4. Sign the contract.

If the contract ends without dispute, each party broadcasts a signed message "Contract with SHA-1 Hash H, completing the transaction without compensation." "Or possible" contract with SHA-1 Hash, the following compensation: … end the transaction", through all the above-mentioned broadcasted signature transaction information, everyone's broadcast each participant to get back to their own Part of the money, delete the contract account.

5. Execute the contract.

If the parties to the contract cannot agree that even with the help of the arbitrator, each participant broadcasts its own version of the contract and the relevant evidence, then each person in the community decides which contract is true based on his or her decision and modifies the balance.

In the second agreement, the database of the account who has much money is saved by some participants (servers) instead of each person. These servers are linked by the broadcast channel in the form of Usenet, and the format of the transaction message broadcast on this channel is still It is the same as the first protocol, but each transaction participant has to verify that the transaction message has been randomly selected and some servers have received and successfully processed.

Since the server must be trusted to some extent by the participants, some mechanism is needed to keep the server honest. Each server that needs to deposit a certain amount of funds in the account will be used as a potential fine or reward for misconduct. In addition, each server must periodically publish and submit its own reserved currency ownership database. Each participant should verify that his or her own account balance is correct. The total account number of the server database cannot exceed the total amount of money issued. This prevents the server from cheating, and even if it is completely collusive, it can prevent the expansion of the money supply permanently and without cost. The new server can also synchronize with existing servers using the published database.

The protocol proposed in this paper allows digital id entities that cannot be tracked to communicate efficiently and implement contractual methods for efficient consensus building.

The agreement may be more effective and safer, and I hope this is a way forward in the practical application and theory of the "encrypted unregulated community concept."

——-

Appendix A: Alternative b-currency creation

One of the more difficult parts of the b-money protocol is the currency issue. This part of the agreement requires all account administrators to decide and agree on the cost of a particular calculation. Unfortunately, because computing technology tends to grow rapidly and is not always open, this information may not be available, inaccurate or outdated, all of which can cause serious problems for the protocol.

So I proposed another currency creation sub-protocol, including the database owner (everyone in the first agreement, or the server in the second agreement), but decided and agreed to the number of b-moneys to be created. In each period, the auction is determined by the cost of creating the money. Each currency creation period is divided into four phases, as follows:

1. Planning.

The database owner calculates and negotiates with each other to determine the best growth of the money supply for the next period. Regardless of whether the database owners can reach a consensus, they each broadcast their currency creation quotas and these evidence supporting these limits.

2. Bidding.

Anyone who wants to create b-money will broadcast the form of the bid <x,y>, where x is the number of b-moneys he wants to create, and y is an unresolved issue in the predetermined difficulty problem class. Each issue should have a nominal cost of public consent in this class (in MIPS years).

3. Calculation.

Once the bid is seen, the bidder will resolve the issue and broadcast the solution.

4. Make money.

Each database owner accepts the highest bidder, and those who actually broadcast the solution receive the appropriate money.

Thinking

I am not a conspiracy theorist, but Nakamoto is too deified by some people.

The "b-money" in this 1998 article seems to be the prototype of Bitcoin. The two kinds of trading media and enforcement contracts mentioned in the article seem to correspond to Bitcoin and Ethereum. There are also articles about timestamp, and there are also contents of asymmetric encryption. Therefore, Nakamoto is also based on the research of his predecessors, creatively proposing and establishing bitcoin.

Nakamoto is very powerful and can even say greatness, but I think he is also a normal person, not a stalker.

Too much worship of individuals will make us lose rational thinking. The deification of Nakamoto will limit the development of Bitcoin. It is not Sakamoto. It is the core concept of Bitcoin that he proposed, but the core ideas of these foundations. The design conforms to the development of a certain stage. If it is not suitable, we should also abandon it, instead of sticking to the original Satoshi Satoshi.

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