How the bitcoin protocol actually works
(A wonderful explanation of the principles of the work of the Bitcoin network by Michael Nielsen. A lot of text, a few pictures. About all the clumsiness of the translation - in a personal, I will correct as it is detected)
Many thousands of articles have been written to explain Bitcoin, an online, peer-to-peer (p2p) currency. Most of these articles superficially describe the essence of a cryptographic protocol, omitting many details. Even those articles that "dig" deeper, often ignore important points. My goal in this publication is to explain the basic ideas behind the Bitcoin protocol in a clear, easily accessible form. We start with simple principles, then we go to a broad theoretical understanding of how the protocol works, and then we will dig deeper, examining raw data in a Bitcoin transaction.
It is quite difficult to understand the operation of the protocol in detail. It is much easier to take Bitcoin for granted instead and participate in speculations about how to get rich with Bitcoin, whether Bitcoin is a bubble, whether Bitcoin can destroy compulsory taxation one fine day, and so on. This is all fun, but it significantly limits your understanding. Understanding the details of the Bitcoin protocol opens up inaccessible prospects. In particular, it is the basis for understanding the built-in scripting language (scripting programming language) Bitcoin, which makes it possible to use Bitcoin to create new types of financial instruments, such as smart contracts ( 1 2 ). New financial instruments can, in turn, be used to create new markets and obtain new forms of collective human behavior.
I will describe concepts such as contracts in the following publications. This publication concentrates on explaining the insides of the Bitcoin protocol. To understand me, you must be familiar with the idea of ​​a public cryptokey , and with closely related ideas about digital signatures . I also assume that you are familiar with the cryptographic hash function (changing the input data by just one bit drastically changes the hash sum, approx. Lane). None of this is very complex. Basic ideas can be obtained from the first-year mathematics programs at the university or computer science classes. Ideas are beautiful, so if you are not familiar with them, I recommend spending a few hours to get acquainted.
')
It may seem surprising that cryptography is the basis of bitcoin. Isn't Bitcoin a currency, not a way to send secret messages? In fact, the problems that Bitcoin has to solve mainly concern security of transactions - be sure that people cannot steal from each other, or impersonate each other, and so on. In the world of atoms, we achieve such security with devices such as locks, safes, signatures, and bank vaults. In the world of bits, we achieve this kind of security using cryptography. And that's why Bitcoin in the shower is a cryptographic protocol.
The strategy, which I will use in my publication, involves the creation of Bitcoin in stages. I will begin by explaining a very simple digital currency based on ideas that are almost obvious. We will call this currency Infocoin to distinguish it from Bitcoin. Of course, our first version of Infocoin will have many flaws, and therefore we will go through several iterations of Infocoin, with each new iteration we will introduce only one or two simple new ideas. After several such iterations, we will come to the full Bitcoin protocol. We will re-open Bitcoin!
This strategy is slower than if I explained the operation of the entire Bitcoin protocol in one gulp. Even if you can understand the mechanics of Bitcoin through such a volley explanation, it will be difficult to understand why Bitcoin is designed in this way. The advantage of a slow, iterative explanation is that it gives us a much clearer understanding of each bitcoin element.
Finally, I have to mention that I'm new to Bitcoin. I have been watching him since 2011 (and cryptocurrency since the late 1990s), but seriously only the beginning of this year got to the details of the Bitcoin protocol. So I will be grateful for correcting any errors on my part. In addition, I included a number of “problems for the author” in my material - notes for myself about the questions I had while writing. You may find them interesting, but you can also skip them completely without losing the main text.
So how can we design digital currency?
At first glance, digital currency seems to be something impossible. Imagine a person — let's call her Alice — she has some digital money she wants to spend. If Alice can use the string of bits as money, how can we stop her from using the same string of bits again and again, thus creating an unlimited amount of money? Or, if we can somehow solve this problem, how can we prevent falsifying such a string of bits and using it to steal from Alice?
These are just two of the many problems that must be overcome in order to use information as money.
In the first version of Infocoin, let's find a way for Alice to use the string of bits in a (very primitive and incomplete) form of money, but in such a way that she has at least some kind of protection against forgery. Suppose Alice wants to give another person, let's call him Bob, an infocoin alone. To do this, Alice writes the message "I, Alice, give Bob one infocoin . " She then signs the message in digital format using the encryption private key (cryptokey), and announces the signed string of bits to the world.
(By the way, I use “Infocoine” with a capital letter to denote a protocol and a general concept, and “infocoin” with a small letter to denote a specific banknote. This practice is common, though not universal, in the Bitcoin world.)
Such a prototype of digital currency will not impress you very much! But he has some virtues. Anyone in the world (including Bob) can use Alice’s public key to verify that Alice was actually the person who signed the message “I, Alice, give Bob an infocoin . ” No one else could have created this string of bits, which means Alice could not turn around and say: “No, I didn’t mean that I wanted to give Bob one infocoin” . Thus, the protocol establishes that Alice really intends to give Bob an infocoin alone. The same fact — no one could compile such a signed message — gives Alice some limited protection against forgery. Of course, after Alice published her message, it is possible to duplicate her message with other people, so that in a sense, fake is possible. But this is not possible from scratch. These two properties — Alice’s intent and limited counterfeit protection — are truly remarkable features of this protocol.
I did not (at all) say that, in fact, there is digital money. I explain: this is just the message itself, that is, the sequence of bits, or rather, the digitally signed message: "I, Alice, give Bob one infocoin . " In the future, the protocols will be similar in that all our forms of digital money will simply be more meaningful messages.
The problem with the first version of Infocoin is that Alice can continue to send the same signed message to Bob over and over again. Suppose Bob receives ten copies of the signed message “I, Alice, give Bob one infocoin” . Does this mean that Alice sent ten different infoocoins to Bob? Was her message accidentally duplicated? Perhaps she was trying to deceive Bob by pretending that she gave him ten different ifochoins, while the message only proves to the whole world that she intends to convey an infocoin alone.
What we would like is to find a way to make infocoins unique. They need a label or a serial number. Alice will sign the message "I, Alice, give Bob one infocoin, with serial number 8740348" . Then, later, Alice can sign the message “I, Alice, give Bob one infocoin, with serial number 8770431” , and Bob (and everyone else) will know that the other infocoin has been transferred.
For this scheme to work, we need a reliable source of serial numbers for infocoins. One way to create such a source is to open a bank. This bank will provide serial numbers for the infocoins, track who has which infocoins, and check that the transactions are indeed legitimate.
More specifically, let's assume that Alice comes to the bank and says: "I want to withdraw (withdraw) one infocoin from my account . " The bank reduces its account balance to one infocoin, and assigns it a new, never-before-used serial number, say 1234567. Then, when Alice wants to transfer her infocoin to Bob, she signs the message “I, Alice, give Bob one infocoin with the sequence number 1234567 " . But Bob doesn't just take infocoin. Instead, he comes in contact with the bank, and checks that: (a) the infocoin with this serial number belongs to Alice; and (b) Alice has not yet spent this infocoin. If the conditions are correct, Bob informs the bank that he wants to take this infocoin, and the bank updates its records to show that the infocoin with this serial number is currently at Bob’s disposal and no longer belongs to Alice.
This latest solution looks pretty promising. However, it turns out that we can do something much more ambitious. We can completely exclude a bank from the protocol. This significantly changes the nature of the currency. This means that there is no longer a single organization responsible for the currency. And if you imagine the enormous power in the hands of the central bank - control over the money supply - this is quite a serious change.
The idea is that everyone (as a whole) is a bank. In particular, we assume that all Infocoin users keep a complete record of who owns the infocoins. You can present this as an open general ledger with all Infocoine transactions. We will call this book the “blockchain”, which is what the public record of all transactions is called in Bitcoin.
Now suppose that Alice wants to transfer infocoin to Bob. She signs the message “I, Alice, give Bob one infocoin with the sequence number 1234567” , and sends the signed message to Bob. Bob can use his copy of the blockchain to check if infocoin really belongs to Alice. If it is checked, then it sends both the message of Alice and the message of acceptance of the transaction throughout the network and all update their copies of the chain of blocks.
We still have the problem “where does the serial number come from,” but it turns out to be quite easy to solve, and therefore I will postpone it until later when we discuss Bitcoin. A more complicated problem is that this protocol allows Alice to cheat through double spending her infocoins. She sends the signed message “I, Alice, give Bob one infocoin with serial number 1234567” to Bob, and the message “I, Alice, give Charlie one infocoin, with [same] serial number 1234567” Charlie. Both, Bob and Charlie, use their copy of the block chain to verify that Infocoin belongs to Alice. Provided that they do this check at the same time (before they had the opportunity to hear from each other), both will see that yes, the block chain shows the ownership of the coin to Alice. So, they both accept the translation and also transmit information about the acceptance of the transaction. Now we have a problem. How should other people update their block chains? It may not be so easy to find a way to get a matching general transaction book. And even if everyone can agree to continuously update their block chains, there is another problem that Bob or Charlie can be deceived.
At first glance, re-expenditure looks difficult for Alice to implement. After all, if Alice sends the message to Bob first, then Bob can check the message and tell everyone else on the network (including Charlie) to update their block chains. Once this happens, Charlie can no longer be fooled by Alice. So, most likely, only in a short period of time Alice can do repeated expenditures. However, obviously, any such time span is undesirable. Worse, there are methods by which Alice can make this period longer. She can, for example, use network traffic analysis to find a time when Bob and Charlie have many delays in communication. Or perhaps she can do something to consciously break their connection. If she can slow down the connection even by a little, then this will simplify her task with re-expenditure.
How can we solve the problem of double costs? The obvious solution would be that when Alice sends Bob an infocoin alone, Bob should not try to verify the transaction alone. Most likely, he should broadcast about the possible transaction to all Infocoin users, and ask them to help him determine whether the transaction is legitimate. If they collectively decide that the transaction is in order, then Bob can accept this infocoin, and everyone will update their block chains. This type of protocol can help prevent the problem of double costs, because if Alice tries to spend her infocoin with Bob and Charlie, other people on the network will notice, and network users will tell Bob and Charlie that there is a problem with the transaction and the transaction should not be carried out.
In more detail, let's assume that Alice wants to give Bob an infocoin alone. As before, she signs the message “I, Alice, give Bob one infocoin with the serial number 1234567” , and gives a signed message to Bob. Just as before, Bob does a health check using his copy of the blockchain to see if the coin really belongs to Alice. But at this moment the protocol is changed. Bob doesn't just go ahead and take the deal. Instead, he transmits Alice's message to the entire network. Other members of the network check if Alice has this infocoin. If so, they send the message "Yes, Alice owns infocoin 1234567, now he can be transferred to Bob." As soon as enough people spread this message online, everyone will update their block chains, which will show that infocoin 1234567 is now owned by Bob and the transaction is complete.
This protocol has many inaccurate elements at this time. For example, what does it mean to say “enough people should broadcast this message”? What does “enough” mean? This cannot mean everyone on the network, since we a priori do not know who is in the Infocoin network. For the same reason, this cannot mean a fixed share of users on the network. We will not try to figure it out right now. Instead, in the next section, I will point out serious problems in the approach we have described. Paying attention to this problem, we will have a pleasant side effect from creating ideas above more understandable.
Suppose Alice wants to re-spend in the protocol I just described. She can do this by taking control of the Infocoin network. Let's assume that it uses an automated system to configure a large number of individual identities (users), say a billion, in the Infocoin network. As before, she tries to pay the same infocoin to Bob and Charlie twice. But when Bob and Charlie ask the network to check the deals, Alice’s additional users will flood the network, announcing to Bob that they have confirmed his deal, and Charlie that they have confirmed his deal, deceiving one or both of them at the same time, accepting such a transaction.
There is a way to avoid this problem using an idea known as proof-of-work. The idea is paradoxical and includes a combination of two other ideas: (1) (artificially) make confirmation of transactions costly for network users in the form of computer calculations; and (2) reward them for helping to verify transactions. The reward is used to ensure that people on the network try to help verify transactions, despite the need to spend computing power on this process. The benefit of the fact that the verification of transactions is costly helps to avoid dependence on the number of identities (network users) controlled by someone. Thus, only total computing power can put pressure on the check. As we will see, using some clever design, we can make it so that the fraudster needs huge computational resources to cheat, which makes it practically impractical.
This is the essence of the proof of the work. But in order to truly understand, we have to look at the details.
Suppose Alice transmits the news to the network, "I, Alice, give Bob one infocoin with the serial number 1234567" .
Upon hearing this message, everyone adds it to the pending queue of pending transactions: heard, but not yet approved by the network. For example, another user on the network named David may have the following queue of pending transactions:
I, Tom, give Sue one infocoin, with serial number 1201174.
I, Sydney, give Cynthia one infocoin, with serial number 1295618.
I, Alice, give Bob one infocoin with the serial number 1234567.
David checks his copy of the blockchain, and sees that each transaction is valid. He would like to help by sending news of the validity of transactions for the entire network.
However, before doing this, as part of the verification protocol, David needs to solve a difficult computational problem — proof of correctness of work. Without solving this problem, the rest of the network will not accept its verification of transactions.
What kind of problem does David need to solve? To explain this, let h be a fixed hash function known to everyone on the network — it is built into the protocol. Bitcoin uses the well-known SHA-256 hash function, but any cryptographically secure hash function will do. Let's give a queue of outstanding deals David label L, so that it is more convenient for us to refer. Suppose David adds the number x (the so-called one-time number) and calculates the hash sum from the combination. For example, if we use L = “Hello, world!” (Obviously, this is not a list of operations, just a string is used for illustration) and a one-time x = 0, then (we get the output in hexadecimal format)
h ("Hello, world! 0") = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64
The task David has to solve is to prove the correctness of the work is to find the prime number x so that when we add x to L and the result of the hashing of the combination begins with a series of zeros. The task can be made more or less difficult by changing the number of zeros needed to solve this task. A relatively simple proof of the correctness of the task may require only three or four zeros at the beginning of the hash, while a more difficult proof of the correctness of the task may require a much larger number of zeros, say 15 consecutive zeros. In any case, the above attempt to find a suitable one-time number with x = 0 failed because the result does not start from zero. Let's try x = 1 ,. It will not work either:
h ("Hello, world! 1") = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8
We can continue to look for different values ​​for x = 2,3,4 .... finally, with the value x = 4250 we get:
h ("Hello, world! 4250") = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9
This number gives us a string of four zeros at the beginning of the output hash. This will be enough to solve the simple problem “proof of work”, but not enough to solve the more difficult problem “proof of work”.
There is a thing that makes this task difficult to solve. The result of a cryptographic hash function behaves like random numbers: change at least one bit in the source data and the result will be radically different so that it is impossible to predict it. So, if we want to have a hash value with 10 zeros at the beginning, then David will need to sort out on average
different x values ​​before he finds a suitable prime number. This is quite a complex task, requiring a large computing power.
It is possible to make this task more or less difficult to solve through more or fewer zeros at the output of the hash function. In fact, the Bitcoin protocol gets a pretty good level of control over the difficulty of the task, using a minor variation of the proof-of-work puzzle described above. Instead of requiring zeros, Bitcoin as a proof of correct operation requires that the hash of the transaction block header be less than or equal to the number known as the target . This goal is automatically adjusted so that the Bitcoin block takes, on average, about ten minutes for authorization.
(In practice, there is considerable randomness in how much time it will take to approve a block - sometimes a new block is approved in just a minute or two, and in other cases it may take 20 minutes or even more. This changes directly in the Bitcoin protocol, so time for testing, it usually reaches a maximum of about ten minutes. Instead of solving one problem, we may require solving several problems; using a carefully designed software design, one can significantly reduce the time variance to check the block Christmas tree.)
Well, let's assume that David was lucky and he found the right number x. Hooray! (He will receive a reward for finding the number, as will be described below). It translates the block of operations that it claims to the network along with the value of x. Other members of the Infocoin network can verify that x is a solution to prove the correctness of the task. And they must then update their block chains to include the new block of operations in the chain.
So that the idea of ​​proving the correctness of a job has a chance of success, network users need an incentive to help them verify transactions. Without such an incentive, they have no reason to spend valuable computing power just to help check other people's operations. And if network users are not willing to spend this power, then the whole system will not work. The solution to this problem is to reward people who help verify transactions. In particular, suppose we reward those who have successfully verified a block of transactions by crediting them with a certain amount of infocoins. The reward for infocoin is so great that it will give them an incentive to participate in the test.
In the Bitcoin protocol, this confirmation process is called mining. For each proven block of transactions, a successful miner receives a reward in bitcoins. Initially, this award was set at 50 bitcoins. But for every 210 thousand checked blocks (approximately once every four years), the reward is halved. This happened only once. To date, the reward for the extraction unit is 25 bitcoins. This rate reduction will continue twice every four years to the year 2140. At that moment, the mining award will fall below 10 ^ -8 Bitcoins per block. 10 ^ -8 Bitcoins, in fact, the minimum Bitcoin unit, and is known as Satoshi . Thus, in 2140, the total supply of bitcoins will cease to increase. However, this does not remove the incentive to continue to validate transactions. Bitcoin also gives you the opportunity to allocate a certain amount in the transaction as a fee for the transaction, which goes to the miner, which helps to accept transactions. In the early days of Bitcoin, the transaction fee was zero, but with the growing popularity of Bitcoin, transaction fees gradually increased, and are now an additional addition to the 25 bitcoin reward for the mining block.
You can think of proof of work (proof-of-work) as a competition who accepts transactions faster. Each entry into the competition costs a bit of processing power. The miner’s chance of winning a competition is (roughly speaking, and with some reservations) equal to the total computing power that they control. For example, if a miner controls one percent of the total computing power used to verify transactions in Bitcoin, then he has about one percent chance of winning.That is, provided that a lot of computing power is involved in the competition, a dishonest miner is likely to have a relatively small chance to distort the verification process, unless he spends a lot of computing resources.
Of course, while it is encouraging that the dishonest party has only a relatively small chance of spoiling the chain of the block, but this is not enough to cause confidence in the currency. In particular, we have not yet finally resolved the issue of recurring costs.
I will analyze the double costs soon. Before doing this, I want to fill in an important detail in the description of Infocoin. It would be ideal to agree on the order in the Infocoine network in which transactions took place. If we do not have such an order, then at any moment it may become unclear who owns which infocoins. To solve this, we will require that new blocks always include a pointer to the previous block approved in the chain, in addition to the list of transactions in the block. (The pointer is actually just a hash of the previous block). So, we have a block chain - it's just a straight chain of transaction blocks, one after another, where each block contains a pointer to the immediately previous block:
Sometimes, a fork appears in the block chain. This can happen, for example, if by chance two miners checked the block of operations at the same time - and both broadcast their newly approved block to the network, and some people update their block chain in one direction, and others update in the other direction:
It would seem that this causes a problem , which we are trying to avoid is no longer clear in what order the transactions took place, and this does not clarify who owns which infocoins. Fortunately, there is a simple idea that can be used to remove any plug. The rule is this: if a plug happens suddenly, people on the network keep track of both branches. But at any time, miners work only on the continuation of the branching in which the replica of the block chain is longer.
Suppose we have a fork in which some miners get block A first and some miners get block B. Those miners who get block A first will continue to work along this branch, while other miners will go along with branch B. Suppose that miners working on branching B successfully extracted the block:
After everyone gets the news that this has happened, miners working on branching A will notice that branching B is now longer and will switch to work on this branching. That's all!Immediately, work on branching A will cease, and everyone will work on the same linear chain, and block A can be ignored. Of course, any unconfirmed transactions included in Block A will still be awaiting a decision in the miners' queues working at the B branch, and subsequently all transactions will be confirmed. In addition, it may be that miners working on branching A will expand it earlier. In this case, the work on branching B is quickly stopped, and again we have one linear chain.
Regardless of the outcome, this process ensures that the block chain has a time-consistent ordering of transaction blocks. In Bitcoin, it is assumed that a transaction is not considered confirmed before: (1) it is part of a block in a long branch, and (2) at least 5 blocks followed it in the longest branch. In this case, we say that the transaction has "6 confirmations". This gives the network time to come to a consistent orderliness of the blocks. We will also use this strategy for Infocoin.
With the ordering, we figured out, let's go back to thinking about what happens if a dishonest user tries to spend twice. Suppose Alice tries to spend the info-info twice with Bob and Charlie. One of the possible approaches for her is to try to independently verify the block, which includes both transactions. Assuming that she has one percent of the total computational power, she might get lucky, and she confirms the block by solving a mathematical problem of the correctness of the work (proof-of-work). Unfortunately, for Alice, the second payment will be immediately noticed by other people on the Ifnokoin network and rejected, despite the solution of the problem with the proof of the correctness of the work. So we do not need to worry.
A more serious problem arises if she broadcasts separately two transactions in which she conducts the same infocoin with Bob and Charlie, respectively. For example, it can transmit one transaction to one group of miners, and another transaction to another, hoping to get approval for transactions in this way. Fortunately, in this case, as we have seen, the network will finally confirm only one of these transactions, but not both. So, for example, Bob’s deal can ultimately be confirmed, in which case Bob can be calm. Meanwhile, Charlie will see that his deal has not been confirmed, and he will refuse Alice’s offer. So there is no problem. In fact, knowing that this is going to happen, there is no particular reason for Alice to try it.
There is another important double cost option if Alice = Bob, i.e. Alice tries to pay the coin to Charlie, which she also “spends” on herself (that is, giving herself away). It looks so that it is easy to notice and cope with it, but at the same time, of course, it is easy to set up several users on the network associated with the same person or organization, so this possibility must be taken into account. In this case, Alice’s strategy is to wait until Charlie accepts infocoin, which will happen after the transaction has been confirmed 6 times in the longest chain. She will try to branch out the chain before the deal with Charlie, adding a block in which the payment transaction is included in itself:
Unfortunately, it is very difficult for Alice to catch up with the longer fork. Other miners do not want to help her, as they will work on a longer fork. And until Alice can solve the proof of correctness of work, at least as quickly as everyone else on the network together - roughly speaking, this means that controlling more than fifty percent of the computing power - it will just lag further and further. behind. Of course, she can get lucky. We can, for example, imagine a scenario in which Alice manages one percent of computing power, but luck happens and she will find six additional blocks in a row before the rest of the network has found any new block. In this case, she could get ahead and gain control over the chain of blocks.But this particular event will occur with a probability of 1 / (100 ^ 6) = 10 ^ -12. A more general analysis in this direction shows that Alice’s probability of catching up with a longer block branching is infinitely small if she is not able to solve the proof of correctness of the work at a speed close to all other miners combined.
Of course, this is not a thorough security analysis, showing Alice’s inability to make repeat expenses. This is just an informal credibility argument. The original text representing Bitcoin, in fact, does not contain a thorough analysis of security, only informal arguments on the points that I presented. A community that is interested in security is still analyzing Bitcoin, and trying to understand possible vulnerabilities. You can see some of these studies here , and I will mention a few problems in “Problems for the author” below (see the original test). At the moment, I think it is fair to say that the jury still does not know how safe Bitcoin is.
Ideas to prove the correctness of work and mining give rise to many questions. What is the reward to convince people to mine? How will changes in the emission of infocoin affect the economy of Ifno-Coin? Will mining Infocoin ultimately be concentrated in the hands of a few, or many? If there are only a few miners, will this put the security of the system at risk? Presumably the cost of transactions will balance over time — will this not lead to an undesirable source of friction, and will it not make small transactions less desirable? These are all big questions that go beyond the scope of this article. I can return to these issues (in the context of Bitcoin) in future publications. Currently, we will focus on understanding how the Bitcoin protocol works.
Let's move away from Infocoin, and describe the actual Bitcoin protocol. There are several new ideas here, but with one exception (see below), that they are mostly obvious modifications of Infocoin.
In order to use Bitcoin in practice, first install a wallet program on your computer. To give you an understanding of what this means, here is a screenshot of a wallet program called Multbit. You can see the bitcoin balance on the left - 0.06555555 bitcoin, or about $ 70 at the rate of the day I took this screenshot - and on the right are two recent deals that form 0.06555555 bitcoins:
Suppose you are a merchant who created an online store and decided to let people pay for your goods using Bitcoin. The first thing you do is generate a Bitcoin address in the program. In response, it will generate a public / private key pair, and then a public key hash to form your Bitcoin address:
Then you send the Bitcoin address to the person who wants to buy from you. You can do this by email, or even put the address publicly on a web page. This is safe because the address is only the value of the hash result of your public key, which can be safely known in the world anyway. (I will return later to the question of why a Bitcoin address is a hash, and not just a public key.)
The person who will pay you generates the transaction. Let's take a look at the data from the real transaction transferring 0.31900000 bitcoins. The following shows the nearly raw data. They are modified in three ways: (1) the data was transformed from a sequential form into a parallel one (deserialized); (2) line numbers that have been added for ease of reference; and (3) I reduced various hashes and public keys by simply displaying the first six hexadecimal digits of each, when in fact they are much longer. Here are the data:
Let's go line by line.
Line 1 contains the hash of the remainder of the transaction, 7c4025 ..., expressed in hexadecimal. This is used as a transaction identifier.
Line 2 tells us that this is a transaction in version 1 of the Bitcoin protocol.
Lines 3 and 4 tell us that the transaction has one input and one output, respectively. I will talk below about transactions with a large number of inputs and conclusions, and why it is useful.
Line 5 contains the value of lock_time, which can be used to control when a transaction is completed. For most Bitcoin transactions today, lock_time is set to 0, which means that the transaction is immediately completed.
Line 6 tells us the size (in bytes) of the transaction. Please note that this is not a cash amount transmitted! About this further.
Lines 7 through 11 define the input bitcoins for the operation. In particular, lines 8 through 10 tell us that the input should be taken from a withdrawal from a previous transaction with a corresponding hash sum, which is expressed in hexadecimal format as 2007ae ... .n = 0 tells us that this will be the first output from that transaction; we will see soon how some of the findings (and inputs) in the transaction work, so don’t worry too much about it now. Line 11 contains the signature of the person transferring the money - 304502 ..., then a space, and then the corresponding public key -04b2d .... Again in hexadecimal format.
The only thing that should be noted about the input is the lack of a precise indication of how many bitcoins from the previous transaction should be spent in this transaction. In fact, all bitcoins from the n = 0th output of the previous transaction are spent. So, for example, if n = 0th withdrawal from a previous transaction amounted to 2 bitcoins, then 2 bitcoins will be spent in this transaction. This seems to be an inconvenient restriction - it's like trying to buy bread with a $ 20 bill, and not being able to break it up into small banknotes. The decision, of course, must have a mechanism for getting change. This can be done using transactions with multiple inputs and outputs, which we discuss in the next section.
Lines 12 through 14 define the withdrawal of bitcoins from a trade. In particular, line 13 tells us the output value: 0.319 bitcoins. Line 14 is a rather complicated process. It is important to note that the value of a7db6f ... is the bitcoin address of the intended recipient of funds (written in hexadecimal format). Actually, line 14 is nothing more than a display of the Bitcoin scripting language. I'm not going to describe this programming language in detail in this article, the main thing for us to understand is that a7db6f ... is just a Bitcoin address.
By the way, now you can see how Bitcoin calls for a problem that I “hid up” in the last chapter: where do the Bitcoin serial numbers come from? In fact, the role of the serial number is played by the hash sum of transactions. In the above transaction, for example, the recipient receives 0.319 bitcoins, which come from the first output of the previous operation with the hash sum 2007ae ... (line 9). If you go and look in the block chain for this transaction, you will see that its output comes from an even earlier transaction. And so on.
There are two clever things about using transaction hash sums instead of serial numbers. First, in Bitcoin there are no really any separate, permanent (virtual) "coins" at all. There is just a long series of deals in the block chain. This is a clever idea to understand that you do not need coins, and you can simply get by with a book of deals. Secondly, when working in this way, we remove the need for any central authority that issues serial numbers. Instead, serial numbers can be generated automatically only by hashing a transaction.
In fact, you can continue to follow the chain of transactions further into the past. Ultimately, this process must end. This can happen in two ways. The first opportunity will arise when you come to the very first Bitcoin transaction contained in the so-called Genesis block . This is a special transaction that has no inputs, but only an output of 50 bitcoins. In other words, this transaction sets the initial money supply. The initial block is accessed separately by clients (programs) of the Bitcoin network. And I will not go into details now, although this is very similar to the deal described above. You can see the serial data converted from serial to parallel here .
The second possibility will be, when you follow the chain of transactions back in time, you will eventually arrive at the so-called basic transaction (coinbase transaction). With the exception of the Initial block, each block of operations in the block chain begins with a special basic transaction. This transaction is a rewarding miner who will verify this block of operations. It uses the same, but not identical, transaction format presented above. I will not go into details on the format, and if you want to see an example, see here . You can read a little more about basic deals here.. Something in which I was not accurate from the one presented above, namely, what specifically is digitally signed on line 11. Obviously, the payer must sign the entire transaction (except for the hash of the transaction that is generated later). Currently, this is not the case - some parts of the transaction are omitted. This makes some parts of the transaction changeable , i.e. they can be changed later. However, this plasticity is not included in the payable amount of senders and recipients that cannot be changed later. I have to admit, I didn't get into the details. As I understand it, this plasticity is under discussion in the Bitcoin developer community, and efforts are being made to reduce or eliminate this plasticity.
In the last section, I described how a single input and one output transaction works. In practice, it is often very convenient to create a Bitcoin transaction with several inputs or several outputs. I'll talk later about why this might be useful. But first, let's take a look at the actual transaction data :
Let's go line by line. This is very similar to a transaction with one input and one output, so I will do it fairly quickly.
Line 1 contains a hash of the rest of the transaction. This is used as a transaction identifier.
Line 2 tells us that this is the transaction version 1 of the Bitcoin protocol.
Lines 3 and 4 tell us that the transaction has three inputs and two outputs, respectively.
Line 5 contains lock_time. As with one input and one output, the value is 0, which means that the transaction is completed immediately.
Line 6 tells us the size of the transaction in bytes.
Lines 7 through 19 define the list of inputs to the transaction. Each corresponds to a withdrawal from a previous Bitcoin transaction.
The first entry is defined in lines 8 through 11.
In particular, lines 8 through 10 tell us that the input should be taken from the n = 0 output from the transaction with the hash value 3beabc .... Line 11 contains the signature, then a space, and then the public key of the sender bitcoin.
Lines 12 through 15 define the second input in a format like lines 8 through 11. And lines 16 through 19 define the third input.
Lines 20 through 24 define a list containing two outputs from a trade.
The first output is defined in lines 21 and 22. Line 21 tells us the output value in 0,01068000 bitcoins. As before, line 22 is an expression of the Bitcoin scripting language. The main thing that is worth paying attention here is, the line e8c30622 ... is the Bitcoin address of the intended recipient of funds.
The second conclusion is defined in lines 23 and 24 in the form like the first conclusion.
One obvious oddity in this description is that although each output has an indication of the amount in Bitcoin associated with it, in the inputs there is no such thing. Of course, the values ​​of the corresponding inputs can be found by referring to the corresponding conclusions in previous transactions. In a standard Bitcoin operation, the sum of all the entries in a transaction must be at least as much as the sum of all the taps. (The only exception to this principle is the Initial block and the basic transactions (coinbase), both form a new offering in the Bitcoin network.) If there are more inputs than conclusions, then the surplus is used as payment for the transaction. It is paid to the miner for a successfully verified block in which the current transaction is included.
That's all about transactions with numerous inputs and outputs! They are a fairly simple variation of transactions with one input and one output.
One good use of such transactions is the idea of ​​surrender. Suppose, for example, that I want to send you 0.15 bitcoins. I can do this by sending you money from a previous transaction in which I received 0.2 bitcoins. Of course, I do not want to send you all 0.2 bitcoins. The solution will send you 0.15 bitcoins, and send 0.05 bitcoins to your Bitcoin address that belongs to me. These 0.05 bitcoins are surrender. This is somewhat different from the process of getting change in the store, since the change in this case is a fee to himself. But the general idea is similar.
This concludes the basic description of the main ideas underlying Bitcoin technology. Of course, I omitted a lot of details - we did not do a technical description. But I described the main ideas for the most common cases of using Bitcoin.
Although the rules of Bitcoin are simple and easy to understand, it does not mean that it is easy to understand all the consequences of these rules. Much more can be said about Bitcoin, and I will explore some of these issues in the future.
I will complete my post with a few controversial points.
How anonymous is Bitcoin? Many people claim that Bitcoin can be used anonymously. This assertion led to the formation of markets such as the Silk Road and various successors who specialize in illegal goods. Meanwhile, the statement that Bitcoin is anonymous is a myth. The blockchain is public and open, which means that everyone can see any Bitcoin transaction ever. Although Bitcoin addresses are not immediately associated with real people, computer scientists have done a great job of figuring out how to de-anonymize "anonymous" social networks. A chain of blocks is an ideal target for these methods. I would be very surprised if the vast majority of Bitcoin users are not identified with a relatively high degree of confidence and ease in the near future. This confidence will not be high enough to reach a guilty plea, but will be high enough to determine likely targets. In addition, identification will be retrospective, which means that those who bought drugs on the Silk Road market in 2011 will still be possible to identify based on the block chain, say, in 2020. These methods of de-anonymization are well known to scientists, and, presumably, to the National Security Agency (USA). I would not be surprised if the NSA and other institutions have already recognized many users. Paradoxically, Bitcoin is often touted as anonymous. This is not true. On the contrary, Bitcoin is perhaps the most open and transparent financial instrument that the world has not yet seen.
Can you get rich with Bitcoin? Well, maybe. Tim O'Reilly once said: “Money is like gas in a car — you have to pay attention or you will end up on the side of the road; but a well-lived life is not a tour of the gas station! “A lot of interest in Bitcoin comes from people whose life stance is aimed at finding a really big gas station. I have to admit, I find it puzzling. In my opinion, it is much more interesting and pleasant to think about Bitcoin and other cryptocurrencies as a way of new forms of collective behavior. It is intellectually fascinating, offers wonderful opportunities for creativity, is socially valuable, and you can also put money into the bank. But if the money in the bank is your main task, then I believe that other strategies are much more likely to succeed.
I omitted the details: although this post described the basic ideas behind Bitcoin, there are many details that I did not mention. Here, for example, is the size preservation feature used by the protocol, based on the data structuring model known as the Merkle Tree . This is a detail, but a great detail, and it is worth finding out more if the data structures are your thing. You can download and explore the original Bitcoin pages . Secondly, I have already spoken a little about the Bitcoin network - issues like how the network deals with denial of service attack, how nodes join and leave the network , and so on. This is a fascinating topic, but it also requires a lot of detail, so I dropped it. You can learn more about this on some of the links above.
Bitcoin Scripting Language: In this article, I explained Bitcoin as a form of digital online money. But this is only a small part of a much larger and more interesting story. As we have seen, every Bitcoin transaction is associated with a script in the Bitcoin programming language. The scenarios that we saw in this material describe simple operations, like "Alice gave Bob 10 bitcoins . " But the scripting language can also be used to express much more complex transactions. In other words, Bitcoin is programmable money . In later publications I will explain the system of scenarios, and how Bitcoin scripts can be used as a platform for experimenting with all kinds of amazing financial instruments.
Translation: Andrey Dubetsky, Igor Korsakov
Many thousands of articles have been written to explain Bitcoin, an online, peer-to-peer (p2p) currency. Most of these articles superficially describe the essence of a cryptographic protocol, omitting many details. Even those articles that "dig" deeper, often ignore important points. My goal in this publication is to explain the basic ideas behind the Bitcoin protocol in a clear, easily accessible form. We start with simple principles, then we go to a broad theoretical understanding of how the protocol works, and then we will dig deeper, examining raw data in a Bitcoin transaction.
It is quite difficult to understand the operation of the protocol in detail. It is much easier to take Bitcoin for granted instead and participate in speculations about how to get rich with Bitcoin, whether Bitcoin is a bubble, whether Bitcoin can destroy compulsory taxation one fine day, and so on. This is all fun, but it significantly limits your understanding. Understanding the details of the Bitcoin protocol opens up inaccessible prospects. In particular, it is the basis for understanding the built-in scripting language (scripting programming language) Bitcoin, which makes it possible to use Bitcoin to create new types of financial instruments, such as smart contracts ( 1 2 ). New financial instruments can, in turn, be used to create new markets and obtain new forms of collective human behavior.
I will describe concepts such as contracts in the following publications. This publication concentrates on explaining the insides of the Bitcoin protocol. To understand me, you must be familiar with the idea of ​​a public cryptokey , and with closely related ideas about digital signatures . I also assume that you are familiar with the cryptographic hash function (changing the input data by just one bit drastically changes the hash sum, approx. Lane). None of this is very complex. Basic ideas can be obtained from the first-year mathematics programs at the university or computer science classes. Ideas are beautiful, so if you are not familiar with them, I recommend spending a few hours to get acquainted.
')
It may seem surprising that cryptography is the basis of bitcoin. Isn't Bitcoin a currency, not a way to send secret messages? In fact, the problems that Bitcoin has to solve mainly concern security of transactions - be sure that people cannot steal from each other, or impersonate each other, and so on. In the world of atoms, we achieve such security with devices such as locks, safes, signatures, and bank vaults. In the world of bits, we achieve this kind of security using cryptography. And that's why Bitcoin in the shower is a cryptographic protocol.
The strategy, which I will use in my publication, involves the creation of Bitcoin in stages. I will begin by explaining a very simple digital currency based on ideas that are almost obvious. We will call this currency Infocoin to distinguish it from Bitcoin. Of course, our first version of Infocoin will have many flaws, and therefore we will go through several iterations of Infocoin, with each new iteration we will introduce only one or two simple new ideas. After several such iterations, we will come to the full Bitcoin protocol. We will re-open Bitcoin!
This strategy is slower than if I explained the operation of the entire Bitcoin protocol in one gulp. Even if you can understand the mechanics of Bitcoin through such a volley explanation, it will be difficult to understand why Bitcoin is designed in this way. The advantage of a slow, iterative explanation is that it gives us a much clearer understanding of each bitcoin element.
Finally, I have to mention that I'm new to Bitcoin. I have been watching him since 2011 (and cryptocurrency since the late 1990s), but seriously only the beginning of this year got to the details of the Bitcoin protocol. So I will be grateful for correcting any errors on my part. In addition, I included a number of “problems for the author” in my material - notes for myself about the questions I had while writing. You may find them interesting, but you can also skip them completely without losing the main text.
First steps: protocol of intent signed
So how can we design digital currency?
At first glance, digital currency seems to be something impossible. Imagine a person — let's call her Alice — she has some digital money she wants to spend. If Alice can use the string of bits as money, how can we stop her from using the same string of bits again and again, thus creating an unlimited amount of money? Or, if we can somehow solve this problem, how can we prevent falsifying such a string of bits and using it to steal from Alice?
These are just two of the many problems that must be overcome in order to use information as money.
In the first version of Infocoin, let's find a way for Alice to use the string of bits in a (very primitive and incomplete) form of money, but in such a way that she has at least some kind of protection against forgery. Suppose Alice wants to give another person, let's call him Bob, an infocoin alone. To do this, Alice writes the message "I, Alice, give Bob one infocoin . " She then signs the message in digital format using the encryption private key (cryptokey), and announces the signed string of bits to the world.
(By the way, I use “Infocoine” with a capital letter to denote a protocol and a general concept, and “infocoin” with a small letter to denote a specific banknote. This practice is common, though not universal, in the Bitcoin world.)
Such a prototype of digital currency will not impress you very much! But he has some virtues. Anyone in the world (including Bob) can use Alice’s public key to verify that Alice was actually the person who signed the message “I, Alice, give Bob an infocoin . ” No one else could have created this string of bits, which means Alice could not turn around and say: “No, I didn’t mean that I wanted to give Bob one infocoin” . Thus, the protocol establishes that Alice really intends to give Bob an infocoin alone. The same fact — no one could compile such a signed message — gives Alice some limited protection against forgery. Of course, after Alice published her message, it is possible to duplicate her message with other people, so that in a sense, fake is possible. But this is not possible from scratch. These two properties — Alice’s intent and limited counterfeit protection — are truly remarkable features of this protocol.
I did not (at all) say that, in fact, there is digital money. I explain: this is just the message itself, that is, the sequence of bits, or rather, the digitally signed message: "I, Alice, give Bob one infocoin . " In the future, the protocols will be similar in that all our forms of digital money will simply be more meaningful messages.
Using Serial Numbers to Mark Coins
The problem with the first version of Infocoin is that Alice can continue to send the same signed message to Bob over and over again. Suppose Bob receives ten copies of the signed message “I, Alice, give Bob one infocoin” . Does this mean that Alice sent ten different infoocoins to Bob? Was her message accidentally duplicated? Perhaps she was trying to deceive Bob by pretending that she gave him ten different ifochoins, while the message only proves to the whole world that she intends to convey an infocoin alone.
What we would like is to find a way to make infocoins unique. They need a label or a serial number. Alice will sign the message "I, Alice, give Bob one infocoin, with serial number 8740348" . Then, later, Alice can sign the message “I, Alice, give Bob one infocoin, with serial number 8770431” , and Bob (and everyone else) will know that the other infocoin has been transferred.
For this scheme to work, we need a reliable source of serial numbers for infocoins. One way to create such a source is to open a bank. This bank will provide serial numbers for the infocoins, track who has which infocoins, and check that the transactions are indeed legitimate.
More specifically, let's assume that Alice comes to the bank and says: "I want to withdraw (withdraw) one infocoin from my account . " The bank reduces its account balance to one infocoin, and assigns it a new, never-before-used serial number, say 1234567. Then, when Alice wants to transfer her infocoin to Bob, she signs the message “I, Alice, give Bob one infocoin with the sequence number 1234567 " . But Bob doesn't just take infocoin. Instead, he comes in contact with the bank, and checks that: (a) the infocoin with this serial number belongs to Alice; and (b) Alice has not yet spent this infocoin. If the conditions are correct, Bob informs the bank that he wants to take this infocoin, and the bank updates its records to show that the infocoin with this serial number is currently at Bob’s disposal and no longer belongs to Alice.
Create a bank with joint efforts
This latest solution looks pretty promising. However, it turns out that we can do something much more ambitious. We can completely exclude a bank from the protocol. This significantly changes the nature of the currency. This means that there is no longer a single organization responsible for the currency. And if you imagine the enormous power in the hands of the central bank - control over the money supply - this is quite a serious change.
The idea is that everyone (as a whole) is a bank. In particular, we assume that all Infocoin users keep a complete record of who owns the infocoins. You can present this as an open general ledger with all Infocoine transactions. We will call this book the “blockchain”, which is what the public record of all transactions is called in Bitcoin.
Now suppose that Alice wants to transfer infocoin to Bob. She signs the message “I, Alice, give Bob one infocoin with the sequence number 1234567” , and sends the signed message to Bob. Bob can use his copy of the blockchain to check if infocoin really belongs to Alice. If it is checked, then it sends both the message of Alice and the message of acceptance of the transaction throughout the network and all update their copies of the chain of blocks.
We still have the problem “where does the serial number come from,” but it turns out to be quite easy to solve, and therefore I will postpone it until later when we discuss Bitcoin. A more complicated problem is that this protocol allows Alice to cheat through double spending her infocoins. She sends the signed message “I, Alice, give Bob one infocoin with serial number 1234567” to Bob, and the message “I, Alice, give Charlie one infocoin, with [same] serial number 1234567” Charlie. Both, Bob and Charlie, use their copy of the block chain to verify that Infocoin belongs to Alice. Provided that they do this check at the same time (before they had the opportunity to hear from each other), both will see that yes, the block chain shows the ownership of the coin to Alice. So, they both accept the translation and also transmit information about the acceptance of the transaction. Now we have a problem. How should other people update their block chains? It may not be so easy to find a way to get a matching general transaction book. And even if everyone can agree to continuously update their block chains, there is another problem that Bob or Charlie can be deceived.
At first glance, re-expenditure looks difficult for Alice to implement. After all, if Alice sends the message to Bob first, then Bob can check the message and tell everyone else on the network (including Charlie) to update their block chains. Once this happens, Charlie can no longer be fooled by Alice. So, most likely, only in a short period of time Alice can do repeated expenditures. However, obviously, any such time span is undesirable. Worse, there are methods by which Alice can make this period longer. She can, for example, use network traffic analysis to find a time when Bob and Charlie have many delays in communication. Or perhaps she can do something to consciously break their connection. If she can slow down the connection even by a little, then this will simplify her task with re-expenditure.
How can we solve the problem of double costs? The obvious solution would be that when Alice sends Bob an infocoin alone, Bob should not try to verify the transaction alone. Most likely, he should broadcast about the possible transaction to all Infocoin users, and ask them to help him determine whether the transaction is legitimate. If they collectively decide that the transaction is in order, then Bob can accept this infocoin, and everyone will update their block chains. This type of protocol can help prevent the problem of double costs, because if Alice tries to spend her infocoin with Bob and Charlie, other people on the network will notice, and network users will tell Bob and Charlie that there is a problem with the transaction and the transaction should not be carried out.
In more detail, let's assume that Alice wants to give Bob an infocoin alone. As before, she signs the message “I, Alice, give Bob one infocoin with the serial number 1234567” , and gives a signed message to Bob. Just as before, Bob does a health check using his copy of the blockchain to see if the coin really belongs to Alice. But at this moment the protocol is changed. Bob doesn't just go ahead and take the deal. Instead, he transmits Alice's message to the entire network. Other members of the network check if Alice has this infocoin. If so, they send the message "Yes, Alice owns infocoin 1234567, now he can be transferred to Bob." As soon as enough people spread this message online, everyone will update their block chains, which will show that infocoin 1234567 is now owned by Bob and the transaction is complete.
This protocol has many inaccurate elements at this time. For example, what does it mean to say “enough people should broadcast this message”? What does “enough” mean? This cannot mean everyone on the network, since we a priori do not know who is in the Infocoin network. For the same reason, this cannot mean a fixed share of users on the network. We will not try to figure it out right now. Instead, in the next section, I will point out serious problems in the approach we have described. Paying attention to this problem, we will have a pleasant side effect from creating ideas above more understandable.
Proof of work
Suppose Alice wants to re-spend in the protocol I just described. She can do this by taking control of the Infocoin network. Let's assume that it uses an automated system to configure a large number of individual identities (users), say a billion, in the Infocoin network. As before, she tries to pay the same infocoin to Bob and Charlie twice. But when Bob and Charlie ask the network to check the deals, Alice’s additional users will flood the network, announcing to Bob that they have confirmed his deal, and Charlie that they have confirmed his deal, deceiving one or both of them at the same time, accepting such a transaction.
There is a way to avoid this problem using an idea known as proof-of-work. The idea is paradoxical and includes a combination of two other ideas: (1) (artificially) make confirmation of transactions costly for network users in the form of computer calculations; and (2) reward them for helping to verify transactions. The reward is used to ensure that people on the network try to help verify transactions, despite the need to spend computing power on this process. The benefit of the fact that the verification of transactions is costly helps to avoid dependence on the number of identities (network users) controlled by someone. Thus, only total computing power can put pressure on the check. As we will see, using some clever design, we can make it so that the fraudster needs huge computational resources to cheat, which makes it practically impractical.
This is the essence of the proof of the work. But in order to truly understand, we have to look at the details.
Suppose Alice transmits the news to the network, "I, Alice, give Bob one infocoin with the serial number 1234567" .
Upon hearing this message, everyone adds it to the pending queue of pending transactions: heard, but not yet approved by the network. For example, another user on the network named David may have the following queue of pending transactions:
I, Tom, give Sue one infocoin, with serial number 1201174.
I, Sydney, give Cynthia one infocoin, with serial number 1295618.
I, Alice, give Bob one infocoin with the serial number 1234567.
David checks his copy of the blockchain, and sees that each transaction is valid. He would like to help by sending news of the validity of transactions for the entire network.
However, before doing this, as part of the verification protocol, David needs to solve a difficult computational problem — proof of correctness of work. Without solving this problem, the rest of the network will not accept its verification of transactions.
What kind of problem does David need to solve? To explain this, let h be a fixed hash function known to everyone on the network — it is built into the protocol. Bitcoin uses the well-known SHA-256 hash function, but any cryptographically secure hash function will do. Let's give a queue of outstanding deals David label L, so that it is more convenient for us to refer. Suppose David adds the number x (the so-called one-time number) and calculates the hash sum from the combination. For example, if we use L = “Hello, world!” (Obviously, this is not a list of operations, just a string is used for illustration) and a one-time x = 0, then (we get the output in hexadecimal format)
h ("Hello, world! 0") = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64
The task David has to solve is to prove the correctness of the work is to find the prime number x so that when we add x to L and the result of the hashing of the combination begins with a series of zeros. The task can be made more or less difficult by changing the number of zeros needed to solve this task. A relatively simple proof of the correctness of the task may require only three or four zeros at the beginning of the hash, while a more difficult proof of the correctness of the task may require a much larger number of zeros, say 15 consecutive zeros. In any case, the above attempt to find a suitable one-time number with x = 0 failed because the result does not start from zero. Let's try x = 1 ,. It will not work either:
h ("Hello, world! 1") = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8
We can continue to look for different values ​​for x = 2,3,4 .... finally, with the value x = 4250 we get:
h ("Hello, world! 4250") = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9
This number gives us a string of four zeros at the beginning of the output hash. This will be enough to solve the simple problem “proof of work”, but not enough to solve the more difficult problem “proof of work”.
There is a thing that makes this task difficult to solve. The result of a cryptographic hash function behaves like random numbers: change at least one bit in the source data and the result will be radically different so that it is impossible to predict it. So, if we want to have a hash value with 10 zeros at the beginning, then David will need to sort out on average
different x values ​​before he finds a suitable prime number. This is quite a complex task, requiring a large computing power.It is possible to make this task more or less difficult to solve through more or fewer zeros at the output of the hash function. In fact, the Bitcoin protocol gets a pretty good level of control over the difficulty of the task, using a minor variation of the proof-of-work puzzle described above. Instead of requiring zeros, Bitcoin as a proof of correct operation requires that the hash of the transaction block header be less than or equal to the number known as the target . This goal is automatically adjusted so that the Bitcoin block takes, on average, about ten minutes for authorization.
(In practice, there is considerable randomness in how much time it will take to approve a block - sometimes a new block is approved in just a minute or two, and in other cases it may take 20 minutes or even more. This changes directly in the Bitcoin protocol, so time for testing, it usually reaches a maximum of about ten minutes. Instead of solving one problem, we may require solving several problems; using a carefully designed software design, one can significantly reduce the time variance to check the block Christmas tree.)
Well, let's assume that David was lucky and he found the right number x. Hooray! (He will receive a reward for finding the number, as will be described below). It translates the block of operations that it claims to the network along with the value of x. Other members of the Infocoin network can verify that x is a solution to prove the correctness of the task. And they must then update their block chains to include the new block of operations in the chain.
So that the idea of ​​proving the correctness of a job has a chance of success, network users need an incentive to help them verify transactions. Without such an incentive, they have no reason to spend valuable computing power just to help check other people's operations. And if network users are not willing to spend this power, then the whole system will not work. The solution to this problem is to reward people who help verify transactions. In particular, suppose we reward those who have successfully verified a block of transactions by crediting them with a certain amount of infocoins. The reward for infocoin is so great that it will give them an incentive to participate in the test.
In the Bitcoin protocol, this confirmation process is called mining. For each proven block of transactions, a successful miner receives a reward in bitcoins. Initially, this award was set at 50 bitcoins. But for every 210 thousand checked blocks (approximately once every four years), the reward is halved. This happened only once. To date, the reward for the extraction unit is 25 bitcoins. This rate reduction will continue twice every four years to the year 2140. At that moment, the mining award will fall below 10 ^ -8 Bitcoins per block. 10 ^ -8 Bitcoins, in fact, the minimum Bitcoin unit, and is known as Satoshi . Thus, in 2140, the total supply of bitcoins will cease to increase. However, this does not remove the incentive to continue to validate transactions. Bitcoin also gives you the opportunity to allocate a certain amount in the transaction as a fee for the transaction, which goes to the miner, which helps to accept transactions. In the early days of Bitcoin, the transaction fee was zero, but with the growing popularity of Bitcoin, transaction fees gradually increased, and are now an additional addition to the 25 bitcoin reward for the mining block.
You can think of proof of work (proof-of-work) as a competition who accepts transactions faster. Each entry into the competition costs a bit of processing power. The miner’s chance of winning a competition is (roughly speaking, and with some reservations) equal to the total computing power that they control. For example, if a miner controls one percent of the total computing power used to verify transactions in Bitcoin, then he has about one percent chance of winning.That is, provided that a lot of computing power is involved in the competition, a dishonest miner is likely to have a relatively small chance to distort the verification process, unless he spends a lot of computing resources.
Of course, while it is encouraging that the dishonest party has only a relatively small chance of spoiling the chain of the block, but this is not enough to cause confidence in the currency. In particular, we have not yet finally resolved the issue of recurring costs.
I will analyze the double costs soon. Before doing this, I want to fill in an important detail in the description of Infocoin. It would be ideal to agree on the order in the Infocoine network in which transactions took place. If we do not have such an order, then at any moment it may become unclear who owns which infocoins. To solve this, we will require that new blocks always include a pointer to the previous block approved in the chain, in addition to the list of transactions in the block. (The pointer is actually just a hash of the previous block). So, we have a block chain - it's just a straight chain of transaction blocks, one after another, where each block contains a pointer to the immediately previous block:
Sometimes, a fork appears in the block chain. This can happen, for example, if by chance two miners checked the block of operations at the same time - and both broadcast their newly approved block to the network, and some people update their block chain in one direction, and others update in the other direction:
It would seem that this causes a problem , which we are trying to avoid is no longer clear in what order the transactions took place, and this does not clarify who owns which infocoins. Fortunately, there is a simple idea that can be used to remove any plug. The rule is this: if a plug happens suddenly, people on the network keep track of both branches. But at any time, miners work only on the continuation of the branching in which the replica of the block chain is longer.
Suppose we have a fork in which some miners get block A first and some miners get block B. Those miners who get block A first will continue to work along this branch, while other miners will go along with branch B. Suppose that miners working on branching B successfully extracted the block:
After everyone gets the news that this has happened, miners working on branching A will notice that branching B is now longer and will switch to work on this branching. That's all!Immediately, work on branching A will cease, and everyone will work on the same linear chain, and block A can be ignored. Of course, any unconfirmed transactions included in Block A will still be awaiting a decision in the miners' queues working at the B branch, and subsequently all transactions will be confirmed. In addition, it may be that miners working on branching A will expand it earlier. In this case, the work on branching B is quickly stopped, and again we have one linear chain.
Regardless of the outcome, this process ensures that the block chain has a time-consistent ordering of transaction blocks. In Bitcoin, it is assumed that a transaction is not considered confirmed before: (1) it is part of a block in a long branch, and (2) at least 5 blocks followed it in the longest branch. In this case, we say that the transaction has "6 confirmations". This gives the network time to come to a consistent orderliness of the blocks. We will also use this strategy for Infocoin.
With the ordering, we figured out, let's go back to thinking about what happens if a dishonest user tries to spend twice. Suppose Alice tries to spend the info-info twice with Bob and Charlie. One of the possible approaches for her is to try to independently verify the block, which includes both transactions. Assuming that she has one percent of the total computational power, she might get lucky, and she confirms the block by solving a mathematical problem of the correctness of the work (proof-of-work). Unfortunately, for Alice, the second payment will be immediately noticed by other people on the Ifnokoin network and rejected, despite the solution of the problem with the proof of the correctness of the work. So we do not need to worry.
A more serious problem arises if she broadcasts separately two transactions in which she conducts the same infocoin with Bob and Charlie, respectively. For example, it can transmit one transaction to one group of miners, and another transaction to another, hoping to get approval for transactions in this way. Fortunately, in this case, as we have seen, the network will finally confirm only one of these transactions, but not both. So, for example, Bob’s deal can ultimately be confirmed, in which case Bob can be calm. Meanwhile, Charlie will see that his deal has not been confirmed, and he will refuse Alice’s offer. So there is no problem. In fact, knowing that this is going to happen, there is no particular reason for Alice to try it.
There is another important double cost option if Alice = Bob, i.e. Alice tries to pay the coin to Charlie, which she also “spends” on herself (that is, giving herself away). It looks so that it is easy to notice and cope with it, but at the same time, of course, it is easy to set up several users on the network associated with the same person or organization, so this possibility must be taken into account. In this case, Alice’s strategy is to wait until Charlie accepts infocoin, which will happen after the transaction has been confirmed 6 times in the longest chain. She will try to branch out the chain before the deal with Charlie, adding a block in which the payment transaction is included in itself:
Unfortunately, it is very difficult for Alice to catch up with the longer fork. Other miners do not want to help her, as they will work on a longer fork. And until Alice can solve the proof of correctness of work, at least as quickly as everyone else on the network together - roughly speaking, this means that controlling more than fifty percent of the computing power - it will just lag further and further. behind. Of course, she can get lucky. We can, for example, imagine a scenario in which Alice manages one percent of computing power, but luck happens and she will find six additional blocks in a row before the rest of the network has found any new block. In this case, she could get ahead and gain control over the chain of blocks.But this particular event will occur with a probability of 1 / (100 ^ 6) = 10 ^ -12. A more general analysis in this direction shows that Alice’s probability of catching up with a longer block branching is infinitely small if she is not able to solve the proof of correctness of the work at a speed close to all other miners combined.
Of course, this is not a thorough security analysis, showing Alice’s inability to make repeat expenses. This is just an informal credibility argument. The original text representing Bitcoin, in fact, does not contain a thorough analysis of security, only informal arguments on the points that I presented. A community that is interested in security is still analyzing Bitcoin, and trying to understand possible vulnerabilities. You can see some of these studies here , and I will mention a few problems in “Problems for the author” below (see the original test). At the moment, I think it is fair to say that the jury still does not know how safe Bitcoin is.
Ideas to prove the correctness of work and mining give rise to many questions. What is the reward to convince people to mine? How will changes in the emission of infocoin affect the economy of Ifno-Coin? Will mining Infocoin ultimately be concentrated in the hands of a few, or many? If there are only a few miners, will this put the security of the system at risk? Presumably the cost of transactions will balance over time — will this not lead to an undesirable source of friction, and will it not make small transactions less desirable? These are all big questions that go beyond the scope of this article. I can return to these issues (in the context of Bitcoin) in future publications. Currently, we will focus on understanding how the Bitcoin protocol works.
Bitcoin
Let's move away from Infocoin, and describe the actual Bitcoin protocol. There are several new ideas here, but with one exception (see below), that they are mostly obvious modifications of Infocoin.
In order to use Bitcoin in practice, first install a wallet program on your computer. To give you an understanding of what this means, here is a screenshot of a wallet program called Multbit. You can see the bitcoin balance on the left - 0.06555555 bitcoin, or about $ 70 at the rate of the day I took this screenshot - and on the right are two recent deals that form 0.06555555 bitcoins:
Suppose you are a merchant who created an online store and decided to let people pay for your goods using Bitcoin. The first thing you do is generate a Bitcoin address in the program. In response, it will generate a public / private key pair, and then a public key hash to form your Bitcoin address:
Then you send the Bitcoin address to the person who wants to buy from you. You can do this by email, or even put the address publicly on a web page. This is safe because the address is only the value of the hash result of your public key, which can be safely known in the world anyway. (I will return later to the question of why a Bitcoin address is a hash, and not just a public key.)
The person who will pay you generates the transaction. Let's take a look at the data from the real transaction transferring 0.31900000 bitcoins. The following shows the nearly raw data. They are modified in three ways: (1) the data was transformed from a sequential form into a parallel one (deserialized); (2) line numbers that have been added for ease of reference; and (3) I reduced various hashes and public keys by simply displaying the first six hexadecimal digits of each, when in fact they are much longer. Here are the data:
- {"Hash": "7c4025 ...",
- "Ver": 1,
- "Vin_sz": 1,
- "Vout_sz": 1,
- "Lock_time": 0,
- "Size": 224,
- "In": [
- {"Prev_out":
- {"Hash": "2007ae ...",
- "N": 0},
- "ScriptSig": "304502 ... 042b2d ..."}],
- "Out": [
- {"Value": "0.31900000",
- "ScriptPubKey": "OP_DUP OP_HASH160 a7db6f OP_EQUALVERIFY OP_CHECKSIG"}]}
Let's go line by line.
Line 1 contains the hash of the remainder of the transaction, 7c4025 ..., expressed in hexadecimal. This is used as a transaction identifier.
Line 2 tells us that this is a transaction in version 1 of the Bitcoin protocol.
Lines 3 and 4 tell us that the transaction has one input and one output, respectively. I will talk below about transactions with a large number of inputs and conclusions, and why it is useful.
Line 5 contains the value of lock_time, which can be used to control when a transaction is completed. For most Bitcoin transactions today, lock_time is set to 0, which means that the transaction is immediately completed.
Line 6 tells us the size (in bytes) of the transaction. Please note that this is not a cash amount transmitted! About this further.
Lines 7 through 11 define the input bitcoins for the operation. In particular, lines 8 through 10 tell us that the input should be taken from a withdrawal from a previous transaction with a corresponding hash sum, which is expressed in hexadecimal format as 2007ae ... .n = 0 tells us that this will be the first output from that transaction; we will see soon how some of the findings (and inputs) in the transaction work, so don’t worry too much about it now. Line 11 contains the signature of the person transferring the money - 304502 ..., then a space, and then the corresponding public key -04b2d .... Again in hexadecimal format.
The only thing that should be noted about the input is the lack of a precise indication of how many bitcoins from the previous transaction should be spent in this transaction. In fact, all bitcoins from the n = 0th output of the previous transaction are spent. So, for example, if n = 0th withdrawal from a previous transaction amounted to 2 bitcoins, then 2 bitcoins will be spent in this transaction. This seems to be an inconvenient restriction - it's like trying to buy bread with a $ 20 bill, and not being able to break it up into small banknotes. The decision, of course, must have a mechanism for getting change. This can be done using transactions with multiple inputs and outputs, which we discuss in the next section.
Lines 12 through 14 define the withdrawal of bitcoins from a trade. In particular, line 13 tells us the output value: 0.319 bitcoins. Line 14 is a rather complicated process. It is important to note that the value of a7db6f ... is the bitcoin address of the intended recipient of funds (written in hexadecimal format). Actually, line 14 is nothing more than a display of the Bitcoin scripting language. I'm not going to describe this programming language in detail in this article, the main thing for us to understand is that a7db6f ... is just a Bitcoin address.
By the way, now you can see how Bitcoin calls for a problem that I “hid up” in the last chapter: where do the Bitcoin serial numbers come from? In fact, the role of the serial number is played by the hash sum of transactions. In the above transaction, for example, the recipient receives 0.319 bitcoins, which come from the first output of the previous operation with the hash sum 2007ae ... (line 9). If you go and look in the block chain for this transaction, you will see that its output comes from an even earlier transaction. And so on.
There are two clever things about using transaction hash sums instead of serial numbers. First, in Bitcoin there are no really any separate, permanent (virtual) "coins" at all. There is just a long series of deals in the block chain. This is a clever idea to understand that you do not need coins, and you can simply get by with a book of deals. Secondly, when working in this way, we remove the need for any central authority that issues serial numbers. Instead, serial numbers can be generated automatically only by hashing a transaction.
In fact, you can continue to follow the chain of transactions further into the past. Ultimately, this process must end. This can happen in two ways. The first opportunity will arise when you come to the very first Bitcoin transaction contained in the so-called Genesis block . This is a special transaction that has no inputs, but only an output of 50 bitcoins. In other words, this transaction sets the initial money supply. The initial block is accessed separately by clients (programs) of the Bitcoin network. And I will not go into details now, although this is very similar to the deal described above. You can see the serial data converted from serial to parallel here .
The second possibility will be, when you follow the chain of transactions back in time, you will eventually arrive at the so-called basic transaction (coinbase transaction). With the exception of the Initial block, each block of operations in the block chain begins with a special basic transaction. This transaction is a rewarding miner who will verify this block of operations. It uses the same, but not identical, transaction format presented above. I will not go into details on the format, and if you want to see an example, see here . You can read a little more about basic deals here.. Something in which I was not accurate from the one presented above, namely, what specifically is digitally signed on line 11. Obviously, the payer must sign the entire transaction (except for the hash of the transaction that is generated later). Currently, this is not the case - some parts of the transaction are omitted. This makes some parts of the transaction changeable , i.e. they can be changed later. However, this plasticity is not included in the payable amount of senders and recipients that cannot be changed later. I have to admit, I didn't get into the details. As I understand it, this plasticity is under discussion in the Bitcoin developer community, and efforts are being made to reduce or eliminate this plasticity.
Operations with multiple entrances and exits
In the last section, I described how a single input and one output transaction works. In practice, it is often very convenient to create a Bitcoin transaction with several inputs or several outputs. I'll talk later about why this might be useful. But first, let's take a look at the actual transaction data :
- . {"Hash": "993830 ...",
- "Ver": 1,
- "Vin_sz": 3,
- "Vout_sz": 2,
- "Lock_time": 0,
- "Size": 552,
- "In": [
- {"Prev_out": {
- "Hash": "3beabc ...",
- "N": 0},
- "ScriptSig": "304402 ... 04c7d2 ..."},
- {"Prev_out": {
- "Hash": "fdae9b ...",
- "N": 0},
- "ScriptSig": "304502 ... 026e15 ..."},
- {"Prev_out": {
- "Hash": "20c86b ...",
- "N": 1},
- "ScriptSig": "304402 ... 038a52 ..."}],
- "Out": [
- {"Value": "0.01068000",
- "ScriptPubKey": "OP_DUP OP_HASH160 e8c306 ... OP_EQUALVERIFY OP_CHECKSIG"},
- {"Value": "4.00000000",
- "ScriptPubKey": "OP_DUP OP_HASH160 d644e3 ... OP_EQUALVERIFY OP_CHECKSIG"}]}
Let's go line by line. This is very similar to a transaction with one input and one output, so I will do it fairly quickly.
Line 1 contains a hash of the rest of the transaction. This is used as a transaction identifier.
Line 2 tells us that this is the transaction version 1 of the Bitcoin protocol.
Lines 3 and 4 tell us that the transaction has three inputs and two outputs, respectively.
Line 5 contains lock_time. As with one input and one output, the value is 0, which means that the transaction is completed immediately.
Line 6 tells us the size of the transaction in bytes.
Lines 7 through 19 define the list of inputs to the transaction. Each corresponds to a withdrawal from a previous Bitcoin transaction.
The first entry is defined in lines 8 through 11.
In particular, lines 8 through 10 tell us that the input should be taken from the n = 0 output from the transaction with the hash value 3beabc .... Line 11 contains the signature, then a space, and then the public key of the sender bitcoin.
Lines 12 through 15 define the second input in a format like lines 8 through 11. And lines 16 through 19 define the third input.
Lines 20 through 24 define a list containing two outputs from a trade.
The first output is defined in lines 21 and 22. Line 21 tells us the output value in 0,01068000 bitcoins. As before, line 22 is an expression of the Bitcoin scripting language. The main thing that is worth paying attention here is, the line e8c30622 ... is the Bitcoin address of the intended recipient of funds.
The second conclusion is defined in lines 23 and 24 in the form like the first conclusion.
One obvious oddity in this description is that although each output has an indication of the amount in Bitcoin associated with it, in the inputs there is no such thing. Of course, the values ​​of the corresponding inputs can be found by referring to the corresponding conclusions in previous transactions. In a standard Bitcoin operation, the sum of all the entries in a transaction must be at least as much as the sum of all the taps. (The only exception to this principle is the Initial block and the basic transactions (coinbase), both form a new offering in the Bitcoin network.) If there are more inputs than conclusions, then the surplus is used as payment for the transaction. It is paid to the miner for a successfully verified block in which the current transaction is included.
That's all about transactions with numerous inputs and outputs! They are a fairly simple variation of transactions with one input and one output.
One good use of such transactions is the idea of ​​surrender. Suppose, for example, that I want to send you 0.15 bitcoins. I can do this by sending you money from a previous transaction in which I received 0.2 bitcoins. Of course, I do not want to send you all 0.2 bitcoins. The solution will send you 0.15 bitcoins, and send 0.05 bitcoins to your Bitcoin address that belongs to me. These 0.05 bitcoins are surrender. This is somewhat different from the process of getting change in the store, since the change in this case is a fee to himself. But the general idea is similar.
Conclusion
This concludes the basic description of the main ideas underlying Bitcoin technology. Of course, I omitted a lot of details - we did not do a technical description. But I described the main ideas for the most common cases of using Bitcoin.
Although the rules of Bitcoin are simple and easy to understand, it does not mean that it is easy to understand all the consequences of these rules. Much more can be said about Bitcoin, and I will explore some of these issues in the future.
I will complete my post with a few controversial points.
How anonymous is Bitcoin? Many people claim that Bitcoin can be used anonymously. This assertion led to the formation of markets such as the Silk Road and various successors who specialize in illegal goods. Meanwhile, the statement that Bitcoin is anonymous is a myth. The blockchain is public and open, which means that everyone can see any Bitcoin transaction ever. Although Bitcoin addresses are not immediately associated with real people, computer scientists have done a great job of figuring out how to de-anonymize "anonymous" social networks. A chain of blocks is an ideal target for these methods. I would be very surprised if the vast majority of Bitcoin users are not identified with a relatively high degree of confidence and ease in the near future. This confidence will not be high enough to reach a guilty plea, but will be high enough to determine likely targets. In addition, identification will be retrospective, which means that those who bought drugs on the Silk Road market in 2011 will still be possible to identify based on the block chain, say, in 2020. These methods of de-anonymization are well known to scientists, and, presumably, to the National Security Agency (USA). I would not be surprised if the NSA and other institutions have already recognized many users. Paradoxically, Bitcoin is often touted as anonymous. This is not true. On the contrary, Bitcoin is perhaps the most open and transparent financial instrument that the world has not yet seen.
Can you get rich with Bitcoin? Well, maybe. Tim O'Reilly once said: “Money is like gas in a car — you have to pay attention or you will end up on the side of the road; but a well-lived life is not a tour of the gas station! “A lot of interest in Bitcoin comes from people whose life stance is aimed at finding a really big gas station. I have to admit, I find it puzzling. In my opinion, it is much more interesting and pleasant to think about Bitcoin and other cryptocurrencies as a way of new forms of collective behavior. It is intellectually fascinating, offers wonderful opportunities for creativity, is socially valuable, and you can also put money into the bank. But if the money in the bank is your main task, then I believe that other strategies are much more likely to succeed.
I omitted the details: although this post described the basic ideas behind Bitcoin, there are many details that I did not mention. Here, for example, is the size preservation feature used by the protocol, based on the data structuring model known as the Merkle Tree . This is a detail, but a great detail, and it is worth finding out more if the data structures are your thing. You can download and explore the original Bitcoin pages . Secondly, I have already spoken a little about the Bitcoin network - issues like how the network deals with denial of service attack, how nodes join and leave the network , and so on. This is a fascinating topic, but it also requires a lot of detail, so I dropped it. You can learn more about this on some of the links above.
Bitcoin Scripting Language: In this article, I explained Bitcoin as a form of digital online money. But this is only a small part of a much larger and more interesting story. As we have seen, every Bitcoin transaction is associated with a script in the Bitcoin programming language. The scenarios that we saw in this material describe simple operations, like "Alice gave Bob 10 bitcoins . " But the scripting language can also be used to express much more complex transactions. In other words, Bitcoin is programmable money . In later publications I will explain the system of scenarios, and how Bitcoin scripts can be used as a platform for experimenting with all kinds of amazing financial instruments.
Translation: Andrey Dubetsky, Igor Korsakov
Source: https://habr.com/ru/post/222493/
All Articles