What is Bitcoin Whitepaper?

Bitcoin White Paper

Bitcoin Whitepaper meaning: Bitcoin is a completely (using) peer-to-peer improved electronic cash, which will support online payment methods that one party sends directly to the other without going through a financial institution. "Digital signatures" provide some solutions, but if a trusted third party is still needed to prevent "double payment", its key value is lost. The solution we propose the “dual payment” problem was to use a “point-to-point” network. The network uses “hashing” to “timestamp” transactions, thereby merging all transactions into a continuous, hash-based “proof of work” chain to form (transaction) records. This record cannot be tampered with unless the "proof of work" is rebuilt. The longest chain not only serves as a proof of the sequence of sighted events, but also (indicates) that the proof comes from the largest CPU computing power pool.

As long as the majority of the CPU power controlled by the nodes does not attack the network in a coordinated and consistent manner, they will generate the longest chain beyond the attacker. The network itself requires very little infrastructure. The information is broadcasted as best as possible, and nodes can leave or rejoin the network at will. All (transactions) that occur during offline periods can be verified by the (supplement) receiving the longest “proof of work” chain.

1. Introduction

Internet commerce has gradually evolved to almost completely rely on financial institutions as trusted third parties to handle electronic payment business. However, even though the system is currently working well enough to handle most transactions, it still suffers from its inherent "trust-based model" flaw. (In Internet commerce,) "completely irreversible transactions" are not really feasible, because they will inevitably involve financial institutions in the mediation of disputes.

The increase in transaction costs caused by this type of mediation cost limits the minimum size of the transaction that can be achieved, at the same time cuts off the possibility of daily small transactions, and there is a broader cost, namely irreversible payments designed for irreversible services Capacity will diminish. Accompanying the possibility of (transaction) revocation is the expansion of trust demand (Because transactions may be unilaterally withdrawn), merchants must be alert to their customers, and consequently constantly annoy customers in order to obtain more information, even if the amount of information is far more than they need.

There is even a reluctance to accept fraud to a certain degree. (Reality) When people use physical currency, these costs and payment uncertainty can be avoided, but (in Internet commerce), no merchant will pay through an information channel without a trusted party.

Therefore, it is necessary to replace the trusted electronic payment system with a certificate based on cryptography. This system allows any two parties with transaction willingness to directly trade with each other without the need of a trusted third party. Transactions that are computationally impossible to reverse will protect the seller from fraud, and regular third-party intermediaries can easily protect buyers. In this paper, we propose a solution to the dual payment problem, which is to use a point-to-point distributed time stamp server to generate a computable, sequenced time sequence transaction proof.
As long as the computing power of the CPU jointly controlled by the honest nodes is more than that of the cooperative attacker node group, the system is safe.

2. The transaction

We stipulate that electronic money is equivalent to a digital signature chain. Each owner transfers his electronic money to the next one, and digitally signs a hash, which is the previous transaction, and the public key of the next owner, and added to the end of the electronic money. The payee can verify the ownership of the chain by checking the signature.

The problem is, of course, that the recipient cannot verify that the owner of a (currency) has not “double-paid” the currency. The common solution is to introduce a trusted central authority (institution), or mint, to check whether each transaction is double-paid. After each transaction is completed, the currency must be recovered to the mint to issue new coins, and only the currency issued by the mint can be trusted without “double payment”. The problem with this solution is that the fate of the entire currency system depends on the company to run the mint, causing every transaction to go through them, like a bank. We need a way to help payees know that their previous owners haven't signed any earlier transactions. For our purposes, the earliest transaction is important so that we don't have to worry about latecomers trying to “double pay”.

The only way to verify the existence of a transaction is to make all transactions known. In the mint-based model, the mint is informed of all transactions and knows which one arrives first. To achieve this without a trusted party, transactions must be publicly broadcast. In this case, we need a system that allows participants to agree on a single history of the order in which they received (transactions). The payee needs to prove the time point of each transaction, and most nodes recognize the transaction as the first transaction received.

3. The timestamp server

Our proposed solution starts with a timestamp server. The timestamp server operates by extracting a hash from a time-stamped block of items and spreading the hash widely, similar to sending a message in a newspaper (advertising) or on a global news network. This timestamp verifies that the data does exist at a certain point in time, and obviously, the purpose is to add to the hash. Each timestamp includes the previous timestamp added to the hash, forming a chain, because each additional timestamp complements its previous timestamp.

4. Proof of workload

To build a distributed time stamp server on a point-to-point basis, we will need a "proof of work" system similar to the "hash cash" created by Adam Baker, not a newspaper or a global news webmail. When performing a hash calculation, the "proof of work" introduces the retrieval of a certain value, such as running SHA-256, and the hash value starts from a certain number of 0 characters. Its (retrieval work) average workload is an index of the required number of 0 characters, and (retrieval work result) can be checked by performing a hash calculation only once.

For our timestamp network, we (supplement) some random number in the block, (by hash calculation, search) the zero string required for the given block hash value, until a value is found, starting with Construct a "proof of work" mechanism. As long as the CPU (as much as possible) computing power is consumed to satisfy the "proof of work" mechanism, the block cannot be modified unless (all) work is performed again. Since the next block is linked thereafter, the workload of modifying the block must include rebuilding all the blocks behind it.

The "proof of work" mechanism also solves the problem of determining candidates for most judgements. If the "majority" is based on "one IP address, one vote", it will be destroyed, because everyone can be assigned many IPs. "Proof of Work" is essentially "one CPU, one vote". The longest chain represents most judgments because the chain has the largest "proof of work" to try to get in. If the majority of the CPU's computing power is controlled by honest nodes, the honest chain will grow faster than other competing chains. To change a completed block, an attacker will be forced to rebuild the block "proof of work", and all subsequent blocks, and then catch up, exceeding the workload of the honest node.

We will mention later that the probability of a slower attacker catching up decreases exponentially due to the subsequent increase in blocks. Over time, the speed of computer hardware continues to increase and the interest of running nodes is volatile. In order to cope with the above situation, the difficulty of the "proof of work" mechanism is to set the average number of blocks generated per hour as a goal If the (block) grows too fast, the difficulty will increase.

5. Network

The steps to run the network are as follows:

i.) New transactions are broadcast to all nodes.

ii.) Each node incorporates new transactions into a block.

iii.) Each node strives to find a "proof of work" with a certain degree of difficulty for its own block.

iv.) When a node finds a "proof of work", it broadcasts the block to all nodes.

v.) (Other) nodes accept the block if and only if all transactions in the block are valid and have never happened before.

vi.) The node indicates the acceptance of the block by appending the work of the next block in the chain, and uses the hash of the accepted block as the (previous hash) of the next block.

A puppet node always considers the longest chain to be correct and will continue to extend the chain. If the description of the next block broadcast by two nodes at the same time point is not consistent, some nodes will take the lead in accepting one or the other block. In this case, they work on the block that they accepted first, but save another fork to prevent it from getting longer. When the next "proof of work" is found and a fork becomes longer, this "tie" will be broken; nodes working on other forks will eventually go to this longer block.

The broadcast of new transactions does not necessarily need to reach all nodes. As long as they reach the majority of nodes, they will be included in a block in a short time. Block broadcasting is also fault-tolerant for missing information. If a node does not receive a block, it will make a (corresponding) request when it receives the next block and realizes that a block is missing.

6. Incentive mechanism

According to the rules, the first transaction in a block is a special transaction that generates a new coin that belongs to the creator of the block. This will increase the incentive for the node to support the network and provide a way to start currency distribution and enter circulation, so this is an issue method without a central institution. This steady and steady increase in the amount of this new currency is similar to gold miners consuming resources to increase gold circulation. In our case, this type of resource is consumed by CPU time and power.

Such incentives can also be seen in transaction costs. If the output value of a transaction is lower than its input value, the difference is the transaction fee, which is used to increase the incentive value of the control transaction block. Once a predetermined amount of money has been (all) entered into circulation, the incentives are all converted into transaction costs (incentives), and inflation can be completely eliminated.

This incentive can also help keep nodes honest. If a greedy attacker is capable of organizing more CPU computing power than an honest node, he will be forced to choose whether to steal fraudulent payments back to him (translator's note: double payment attack) or to generate new currency. He should find that it is more profitable to follow the rules. Such rules will help him acquire more new currency than everyone else united, and it is better than destroying the system and damaging the effectiveness of owning wealth.

7. Recover disk space

Once the last transaction in a currency is included in enough blocks, the previously invalidated transactions can be discarded to save disk space. To ensure that the hash of the block is not destroyed at the same time, the transactions are randomly hashed on a "Merkle Tree", and only its "root" is placed in the block. Greek. Just pruning other branches of this tree, the previous blocks can be compressed. No need to save the built-in hash.

The header of a block without transactions (information) is approximately 80 bytes. If you want to generate a block every 10 minutes or so, it will be about 4.2MB per year (space required) (80B × 6 × 24 × 365 = 4.2MB). In view of the fact that computer systems are usually sold with a random 2GB storage space in 2008, and Moore's Law indicates that the current growth rate is 1.2GB per year, even if the block header must be kept permanently, storage (space) is not a problem.

Payment verification is also possible without running all nodes in the entire network. The user only needs to keep a backup of the first block of the longest "proof of work" chain. Therefore, he can query the nodes in the network until he is confident that he has the longest blockchain. The purpose of a branch to connect transactions to timestamped blocks. He cannot check the transaction by himself, but by connecting to a certain position on the chain, he can see that a network node has accepted the transaction, and the additional blocks later confirm that the network has accepted the transaction .

8. Simplified payment verification

At this time, as long as the honest node controls the network, the verification is reliable, but if the network is overwhelmed by the attacker, it is very vulnerable to attack. Although network nodes can verify their transactions on their own, as long as the attacker can continue to suppress the network, the easy method will be fooled by the attacker's forged exchange. A targeted protection strategy must be adopted to receive an alarm signal when a network node finds an invalid block, and prompt the user software to download the entire block and the alarmed transaction to confirm its inconsistency. Due to more autonomous security guarantees and faster verification considerations, commercial organizations that accept large daily frequent payments are likely to still want to run their own nodes.

9. The merger and division of value

Although it is possible to deal with a single currency, it will become inconvenient to split a transaction for each currency in a transfer. To allow value to be split and merged, transactions include multiple inputs and outputs. Normally, it is either a single input from a previous larger transaction or multiple inputs combined with a smaller amount (transaction), and the output is at most two: one for payment; another for change (If any, all returned to the purchaser).

At this time, it is necessary to pay attention to the output side, where a transaction depends on multiple transactions, and these multiple transactions depend on more transactions, which is not a problem. Never need to extract a completely separate backup of the transaction history.

10. Privacy

The traditional banking business model builds privacy levels by restricting affiliates' access to data entry and trusted third parties. The need to publicly broadcast all transactions hinders this approach, but privacy can still be guaranteed by blocking the flow of information elsewhere: using public keys held anonymously. The public can see someone paying someone a certain amount of money, but there is no information to connect this transaction to anyone. This is similar to how the stock exchange publishes information, where the time and scale of individual transactions, or "quotations," are public, but they do not tell who the transaction is.

As a supplementary firewall, a new pair of keys is used for every transaction to prevent them from connecting to an ordinary owner. Some connections are still inevitable, because transactions with multiple inputs will inevitably leak out that their inputs are from the same owner. The real danger is that if the owner's private key is compromised, the connection will reveal other transactions belonging to that same owner.

11. Calculation

We imagine a scenario: An attacker tries to generate an alternative chain faster than an honest chain. Even if its technology is superb, it still can't tamper with the system suddenly and tamper with it, such as creating value out of nothing or plundering wealth that never belongs to him. Nodes will not accept an invalid transaction as a payment, and honest nodes will not accept a block containing the invalid transaction. An attacker can only attempt to tamper with a transaction of his own in order to recover the money recently consumed. The race between the honest chain and the attacker chain can be described as a "Binomial Random Walk." A successful event is one block extended by the honest chain, then the lead is increased by "+1"; a failed event is an attacker's chain extended by one block, and the gap is reduced by "-1".

The probability that an attacker will catch up from a given loss is similar to the "gambler bankruptcy problem". Suppose that a gambler has unlimited overdraft credit and (he) starts with a loss and can perform an unlimited number of tests to try to reach the breakeven point. We can calculate the probability that he may reach the break-even point or that the attacker catches up with the honest chain, as follows:

p = probability that honest nodes will find the next block

q = probability that the attacker will find the next block

qz = probability of attacker catching up after block Z

We give an assumption, p> q, and the probability decreases exponentially as the number of blocks that an attacker has to catch up keeps increasing. As the odds are inconsistent with it, if he is not lucky enough to make rapid progress in the early days, he will be left behind far away, and his tampering will be minimal. We are now considering how long the payee of this new transaction will have to wait before it is fully established that the payer cannot modify the transaction. Let's assume that the payer is an attacker, and he wants the payee to believe that the payment has been made at that time, and after a period of time, change it to pay to himself.

When things happen, the payee is alarmed, but the payer hopes it is too late. The payee generates a new pair of keys, gives the public key to the payer, and reserves a short time before signing. This will prevent (the following things) from happening: the payer prepares the blockchain in advance by working continuously, until he is very lucky to reach far enough ahead (that is, his blockchain length exceeds the honest blockchain length), Then execute the transaction.
Once the transaction is sent, the dishonest payer secretly begins work on a parallel chain containing an alternative version of his transaction. The payee waits until the transaction has been included in a block, and Z blocks are already connected. He does not know the exact amount of growth (blocks) that the attacker has created, but assuming that the honest block is expected to spend an equal amount of time on each block, the potential growth of the attacker block will be "Poisson distribution", the expected value for:

In order to obtain the probability that the attacker will catch up, we multiply the probability density of the Poisson distribution of the number of blocks that the attacker has made progress with the probability that the attacker can still catch up with this number:

Is converted to the following form to avoid the sum of infinite series.
Convert to C language code
Running results, we can see that the probability Z value decreases exponentially. Solve to make Z less than 0.1%.

Conclusion

We propose an electronic trading system that does not require trust. At the beginning, we introduced (ie introduced) a common framework for generating currency based on digital signatures, which provides strong ownership control but cannot completely prevent "double payment". To solve this problem, we propose a peer-to-peer network, which uses "proof of work" to record a public transaction history. For an attacker, if most of the CPU power of the peer-to-peer network is honest Node-controlled, then tampering (recorded behavior) quickly becomes computationally impractical.
The network is robust and robust due to its simple and arbitrary topology. Nodes need little coordination to work together. They do not need to identify (identity), because (transaction) information does not need to be routed to some specific areas, it only needs to do their best to spread it. Nodes can leave and reconnect to the network at any time. All transactions that occur during offline periods can be verified by (supplementally) receiving the "proof of work" chain. They vote with CPU hash power, and express their opinions by striving to extend valid blocks and refusing to extend after invalid blocks, that is, whether to accept the opinions of a certain block. Through this consensus mechanism, any necessary rules and incentives can be enforced.

See also:

For Highly Beneficial Crypto Networking Please Connect at Crypto Network

halalbarqat.com

Search This Blog