BitCoin what is it?

Real money?

The first place in the list of major misconceptions about Bitcoin is the idea that Bitcoin is another "piece of paper", even electronic ones that only represent "real" money, are such debt receipts. Hence the origin of most of the other fallacies: if these are pieces of paper, then they are worthless; They can be printed or destroyed as many as you like; They can be faked; They can be copied

I repeat - all this is nothing more than delusions. At the heart of the idea of ​​Bitcoin lay the desire to create not just another "piece of paper" that represents real money, such as gold, but an analog of gold itself. Take those properties of gold, due to which it is the ideal money, and make an electronic currency on their basis.

Complexity of extraction

Gold can not be copied - it can only be obtained. But this is a very costly process both in time and in resources. Partly because of this, gold is valued so highly. To make it clearer, let's look at an example.

Suppose a person all day zealously extracted gold and extracted as a result 1 kg. For him, the cost of gold mined is one day of hard work. After a hard day, he decided to rest and go to the cinema. By happy coincidence, the cashier gave tickets in exchange for gold. Why? Because the cashier likes gold, but I do not like working with a pick all day. Therefore, he is ready to provide a service - to give a ticket - in exchange for 1 kg of gold. In fact, he exchanges his service for one day of hard work.

Now let's imagine a different situation. Invented a copier that works with gold. And any person can make 10 kg from 1 kg of gold per minute. In this situation, the cashier will no longer exchange tickets for gold, since now he can easily print it as much as he likes. Gold will cease to have any value and it can no longer be used as money.

In Bitcoin, the process of collecting coins also requires resources and time. But in this case it's not human resources, but computer resources.

Conditionally limited resource

The longer gold is mined, the more difficult (more costly by resources) it becomes to extract it. This ensures that inflation will be under control.

In Bitcoin, similar behavior is achieved by introducing a function of the speed of the total produced coins from time to time. This function is inversely proportional, that is, the velocity decreases with time and tends to zero. If we take the integral of this function with respect to time, we get an exponential. Approximately this:

It can be seen that the total number of coins tends to 21,000,000. The details of the work of Bitcoin will be examined further. In the meantime, you need to know two things: coins appear in the system in batches approximately every 10 minutes, the number of coins in one bundle is 50, and it decreases twice every 4 years.

Materiality

This is already a property not so much of gold as of any non-electronic currency. One ingot of gold can not be exchanged for a service or an item twice. That is, at one point in time it can be either from the seller or from the buyer.

This behavior is natural for a material currency, but not for electronic currency. To achieve this behavior of virtual money, you need to make a lot of wits. In Bitcoin, this behavior is provided by the transaction mechanism. All transactions are merged into chains. Each transaction takes coins from one or more existing transactions and indicates to whom they are targeted. Therefore, you can always check the entire chain for validity.

Complexity of extraction, limited resource, materiality - these properties, plus the use of cryptography for security, allow Bitcoin to be used as money. They are based on the Bitcoin core. This is not just an arrangement. All of them are incorporated in the system by design, and in another way it will not work. It's time to consider this very design.

Chain of Blocks

Any electronic payment system should somewhere and somehow store transactions. In Bitcoin, all information is stored in a chain of blocks. The blocks are transmitted in JSON format. Each block contains a header and a list of transactions. The header consists of several properties, among which there is a hash of the previous block. Thus, the entire block chain stores all transactions for the entire time Bitcoin runs.

In the current versions of the Bitcoin program, the block chain is downloaded entirely by each client, which makes the system completely decentralized. Data is not encrypted in any way and anyone can manually track all transactions. There is even a special site - Bitcoin Block Explorer, where you can easily see all the information about the blocks and transactions.

At the time of this writing, the number of blocks in the chain was 110 968, and, as I said earlier, this number increases by about 1 every 10 minutes. This means that one of the participants was able to create a new block.

This works as follows. One of the clients creates a new transaction and sends it to other customers who are busy generating the block. They add this transaction to their block and continue to generate. Sooner or later someone will be able to generate a block. Such a block is sealed (no more transactions are added to it) and sent over the network. Next, clients check the block and the transactions inside it for validity. If there are no problems, the transactions are considered approved. By this time, the fresh block has already reached every customer and is added to the chain. After that, the process is repeated - the customers begin to generate the next block and collect new transactions into it.

Block

Consider the contents of the block and the process of generating it in more detail. An example block can be found on the same Bitcoin Block Explorer . The block consists of a header and a list of transactions. The header consists of the following properties:

• Hash - SHA-256 header hash of the block. Such a hash is rather random, and the time of its calculation is predictable. I want to note that only the header is hashed, without transactions. So the number of transactions will not greatly affect the time of computation of the hash.
• Ver - The version of the block scheme. At the moment, all the blocks have one version - 1.
• Prev_block - Hash the previous block in the chain. Due to this property, the chain can not be faked by replacing one of the blocks in it, since the hash of the block always depends on the hash of the previous block in the chain. Changing one of the blocks, you will have to recreate all the subsequent ones.
• Mrkl_root - Merkle root - list of transaction hashes. The block hash must necessarily depend on transactions, so that they can not be faked. But to calculate it directly will be long, if the number of transactions is large. Therefore, the transactions themselves are hashed first, and then their hashes are used to calculate the hash of the entire block.

It may seem absurd - why double-calculate the hash of the same. But the fact is that the transaction hash is updated only when adding a new transaction to the block, and the hash of the block header is recalculated several thousand times per second. In addition, the closer the size of the header in the constant, the more accurately you can predict the time it takes to compute its hash.

• Time - uint32_t representing the time the block was created. The maximum permissible year is 2106.
• Bits - One of the most important properties. It is a shortened form of the target hash value. A block is considered to be generated (valid) when its hash is less than this target value. The target value determines the complexity of creating the block. The smaller it is, the less likely it is to select a suitable hash in one iteration. This property is updated every two weeks.

This is as follows. The number of blocks generated in the last two weeks is calculated and compared with the standard (1 block every 10 minutes). If there are too many blocks, then the complexity increases. If the blocks are too small - decreases. Thus, the system adapts to the increase in the number of users and, as a result, the total capacity of their computers.

• Nonce - A number that, starting from zero, is incremented after each iteration of the hash calculation. Actually, this is the case, until the hash is less than the target value. For each new hash to differ from the previous one, at least one of the properties of the block header must be different.

For example, the version never changes. The hash of the previous block is updated when someone overrides us and generates a new block. Merkle root is updated when you add a transaction. Time is every few seconds. Bits (target value, complexity) - every two weeks. It's all too long. To not wait until one of the properties is updated and there is a nonce.

Let's consider a hypothetical situation. All nonce values ​​have been checked and none of them is suitable. During this time, no other property has changed. There is a nonce overflow and it starts again from scratch. It turns out that then the hashes will be repeated. To avoid such situations, after a nonce overflow, the special property of one of the transactions changes. After this, Merkle root is updated and the headers of the block header hashes will no longer be repeated.

• N_tx - Number of transactions in the list.
• Size - The block size in bytes.

Transactions

Transactions are contained in blocks in the form of a list. They, like blocks, line up in chains. Each transaction must specify where it takes the money (from which existing transaction), and where it directs.

To specify the addressee, its public key is used. To the recipient could use the money, he must create a new transaction that will take money from the previous one and redirect them to another address. To prove that a person uses his money, rather than someone else's, to translate, he must leave his digital signature in his transaction. Then at any time you can make sure that all transactions in the system are valid.

In practice, all this is realized with the help of the following properties:

• Hash - The hash of the entire transaction. It turns out that transactions are hashed twice. The first time during the calculation of the transaction hash. The second time during the calculation of the block hash. In addition, each block refers to the hash of the previous block, and each transaction to the hash of the previous transaction (or transactions). If you change the transaction, and somehow miraculously, its hash does not break, then all other hashes will break and the changed chain of blocks will be rejected by all clients.
• Ver - The version of the transaction scheme. So far it has never changed, so it is everywhere equal to 1.
• Vin_sz - The number of previous transactions, from which money is transferred to new addresses. One or more.
• Vout_sz - Number of addresses to which money is transferred. One or more.
• Lock_time - Not yet used and everywhere equal to 0. The idea is to create pending transactions so that they are added not to the current generated block, but, for example, to the next one. It is assumed that this property indicates the number of blocks that the transaction should skip before adding. This allows you to change the transaction and re-sign it for some time.
• Size - The size of the transaction in bytes. The size of the transaction in JSON format is implied.
• In - Contains a list of transaction inputs (sources). The inputs are the outputs of the previous transactions (prev_out). Each output has the following properties:
  • Hash - The hash of the previous transaction.
  • N - Since a transaction can have multiple outputs, you need to specify which of them the money is taken from. For this, there is this property. It contains the sequence number of the output of the previous transaction, starting with 0.
  • ScriptSig - In this property, the sender must prove that he is translating his own money, not someone else's. To do this, it specifies the public key of the recipient of the previous transaction, that is, its own key, since it must be the recipient. In addition, it adds ECDSA to the signature of the same transaction, which is made by its private key. This proves that he disposes of his money, and not of strangers.

After the list of inputs of the transaction (in), a list of outputs (out), i.e., addresses, is indicated. Each output has the following properties:

• Value - Contains the amount of money that will be transferred to the new address. They are taken from previous transactions. Therefore, this number should not exceed their amount. For example, we want to take 10 coins from one transaction and 20 from another and send 25 to a new address. That the remaining 5 coins are not lost, we send them to ourselves, as a change. Thus, in our transaction there will be two recipients, one of which is ourselves. Value is always specified in nanomonets to avoid fractional numbers.
• ScriptPubKey - This property, together with scriptSig, forms a script on the modified

The total amount of money at the entrance of the transaction is always equal to the total amount at the output. Otherwise, money either arose from the air, or disappeared from circulation. But at the very beginning there was a graph showing that the number of money is growing exponentially. So where do the new money come from?

For my taste, the issue of money is simple and elegant. In each block, the first transaction in the list is a special transaction. It always has one input, which instead of the scriptSig property has a coinbase property. This property can contain anything.

The stability of the system is based on the number of users who have an official client running. While their majority, Bitcoin does not threaten anything.

Conclusion

Proof of work (proof of work) is the result of a work that is difficult to achieve, but easy to verify. The work of the Bitcoin network is based on this principle. Check the hash (the result of the work) in a fraction of a second. And in order to pick it up, it takes a lot of work.

Here you can recall the analogy with gold, the extraction of which takes a lot of time and resources. But to understand that before you gold, you can almost immediately. In this sense, Bitcoin also has its value. But you do not need to understand this as a price in dollars or in electricity bills that the computer used when selecting a hash.

The price in dollars is a bit different. It is not embedded in Bitcoin and is determined solely by the market. After all, gold itself does not guarantee you a certain price in dollars. It is guaranteed only by a person who wants to exchange gold for dollars.

The original value of gold was determined solely by those who extracted it. For the gold mined, he asked so much that it was possible to compensate for the effort to extract it. And only after that the market starts to influence the price of gold.

Once Bitcoin is on the market, its value is determined solely by the level of trust in the system. The more people are trusted, the more Bitcoin will be bought, the more dollars will be invested in it and, as a consequence, the more expensive Bitcoin will be.

Before people can trust Bitcoin, they must find out whether this system has a sufficient degree of security, and whether it can be used as money, ie, whether it has the properties of money that I listed in the beginning. Learn this for sure you can only disassemble in the principles of Bitcoin.

I hope that after this article with Habarhabar, the level of confidence in Bitcoin will at least grow a little.