How to actually work Bitcoin protocol

How to actually work Bitcoin protocol

Many thousands of articles were written in order to explain Bitcoin – online, peer-to-peer (p2p) currency. Most of these articles sketchily describe the essence of the 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 that lie in 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 dig deeper, considering the raw data in Bitcoin transaction.

It is quite difficult to understand the protocol in detail. It is much easier instead to accept Bitcoin as a given and participate in speculation about how to get rich with Bitcoin, whether Bitcoin is a bubble, whether Bitcoin can one day destroy compulsory taxation, and so on. It’s all fun, but it essentially limits your understanding. Understanding the details of the protocol Bitcoin offers an inaccessible perspective. In particular, this is the basis for understanding the built-in script language (scripting programming language) Bitcoin, which makes it possible to use Bitcoin to create new types of financial instruments, such as smart contracts (Bitcoin Smart contract). New financial instruments can, in turn, be used to create new markets and generate new forms of collective behavior.

I will describe such concepts as contracts in the following publications. This publication focuses on explaining the interior of the Bitcoin protocol. To understand me, you need to be familiar with the idea of ​​public crypto key, and closely related ideas about Electronic signatures. I also assume that you are familiar with the cryptographic hash function (changing just one bit of input data drastically changes the hash sum, note 1). None of this is very complex. The main ideas can be obtained from the programs of the first year in mathematics at the university or classes in computer informatics. Ideas are beautiful, so if you are not familiar with them, I recommend spending several hours to get acquainted.

It may seem surprising that cryptography is the basis of Bitcoin. Is Bitcoin not a currency, not a way of sending secret messages? In fact, the problems that Bitcoin has to solve relate primarily to securing transactions – to be sure that people can not steal from each other, or impersonate each other, and so on. In the world of atoms, we achieve such security with the help of devices such as locks, safes, signatures and bank vaults. In the bit world, we achieve this kind of security with the help of cryptography. And that’s why Bitcoin in the shower is a cryptographic protocol.

The strategy that 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 practically obvious. We will call this currency Infocoin to distinguish it from Bitcoin (forecasts about the future of bitcoin). Of course, our first version of Infocoin will have many drawbacks, and therefore we will go through several iterations of Infocoin, with each new iteration we will enter only one or two simple new ideas. After several such iterations, we come to the complete protocol Bitcoin. We will rediscover Bitcoin and you will know How to actually work Bitcoin protocol!

This strategy is slower than if I explained the operation of the whole protocol Bitcoin 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 this way. The advantage of a slow, iterative explanation is that this gives us a much clearer understanding of each Bitcoin element.

Finally, I must mention that I’m new to Bitcoin. I have been watching him since 2011 (and for crypto-currencies since the late 1990s: Bitcoin Brief History), but seriously considered the details of the Bitcoin protocol only at the beginning of this year. So I will be grateful for correcting any errors on my part. In addition, I included in my material a number of “problems for the author,” notes for myself about the issues that arose at my writing. You can find them interesting, but you can also skip them completely without losing the main text.

First steps: signing a protocol of intent

So how can we design a digital crypto-currency?

At first glance, the digital currency seems to be something impossible. Imagine a person – call her Alice – she has some digital money that she wants to spend. If Alice can use a string of bits as money, how can we prevent her from using the same bit string over and over, thus creating an unlimited amount of money? Or, if we can somehow solve this problem, how can we prevent forging such a string of bits and using it to steal from Alice?

These are just two of the many problems that need to be overcome in order to use information as money.

In the first version of Infocoin, let’s find a way for Alice to use a 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 to another person, let’s call him Bob, one infocoin. To do this, Alice writes down the message “I, Alice, give Bob one infokoin.” Then she signs a digital message using a private encryption key (cryptic key), and announces a signed string of bits to the world.

(Incidentally, I use “Infocoin” with a capital letter to indicate the protocol and the general concept, and “infocoin” with a small letter to indicate a particular currency.) This practice is common, although not universal, in the Bitcoin world.)

Such a prototype of a digital currency will not impress you very much! But he has some advantages. Any person 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 one infocoin.” No one else could create this string of bits, which means that Alice can not turn around and say: “No, I did not mean that I want to give Bob one infocoin.” Thus, the protocol establishes that Alice really intends to give Bob one infokoin. The same fact – no one could make such a signed message – gives Alice some limited protection from forgery. Of course, after Alice has published her message, it is possible to duplicate her message by other people, so in a sense, a fake is possible. But this is not possible from scratch. These two properties – the establishment of Alice’s intentions and the limited protection against forgery – are truly remarkable features of this protocol.

I (at all) did not say that, in fact, there is digital money. I explain: it’s just the message itself, i.e. the sequence of bits, or more precisely, the digitally signed message: “I, Alice, give Bob one infokoin.” 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 identify coins

The problem with the first version of Infocoin is that Alice can continue to send Bob the same signed message again and again. Suppose Bob gets ten copies of a signed message “I, Alice, give Bob one infocoin.” Does this mean that Alice sent Bob ten different infocoins? Was her message accidentally duplicated? Perhaps she was trying to deceive Bob, pretending that she gave him ten different iPhonocoids, while the message only proves to the whole world that she intends to pass one infocoin.

What we would like is to find a way to make infocoins unique. They need a label or serial number. Alice will sign the message “I, Alice, give Bob one infokoin, 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 another infokoin was transferred.

In order 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 infokoinov, track who has what infokoiny, and verify that the transaction is indeed legitimate.

More specifically, let’s assume that Alice comes to the bank and says: “I want to withdraw one infocoin from my account.” The bank reduces its account balance by one infocoin, and assigns it a new serial number, never before used, say 1234567. Then, when Alice wants to transfer her infocoin to Bob, she signs the message “I, Alice, give Bob one infocoin with the serial number 1234567 “. But Bob does not just take infocoin. Instead, he comes into contact with the bank, and checks that: (a) the infokoin 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 receive this infocoin, and the bank updates its records to indicate that the infocoin with this serial number is currently available to Bob and no longer belongs to Alice.

Create a bank with joint efforts

This last solution looks rather promising. However, it turns out that we can do something much more ambitious. We can completely exclude the 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 represent the huge power in the hands of the central bank – control over the money supply – this is a pretty serious change.

The idea is that everyone (in the aggregate) is a bank. In particular, we assume that all Infocoin users store a complete record of who the infocoins belong to. You can imagine this as an open general accounting book with all Infocoin operations indicated. We’ll call this book a “blockchain”, which is exactly what BitQoin calls a public record of all transactions.

Now suppose that Alice wants to pass the infocoin to Bob. She signs the message “I, Alice, give Bob one infocoin with the serial number 1234567”, and sends the signed message to Bob. Bob can use his copy of the chain of blocks to check if the infokoin really belongs to Alice. If this is checked, then he sends both Alice’s message and his message about accepting the transaction all over the network and everyone updates their copies of the chain of blocks.

We still have a problem “where does the serial number come from”, but it turns out that it’s quite easy to solve, and therefore I will postpone it for later, when we will discuss Bitcoin. A more complex problem is that this protocol allows Alice to cheat through the repeated expenditure (double spending) of her infokoinov. She sends a signed message “I, Alice, give Bob one infocoin with the serial number 1234567” to Bob, and the message “I, Alice, give Charlie one infocoin, with [the same] serial number 1234567” Charlie. Both Bob and Charlie use their own copy of the chain of blocks to verify that infokoin 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 chain of blocks shows the identity of the coin Alice. So, they both accept the transfer and also broadcast information about the acceptance of the transaction together. Now we have a problem. How do other people need to update their block chains? It may not be so easy to find a way to obtain a matching general transaction book. And even if everyone can agree on an ongoing basis to update their block chains, there is another problem that Bob or Charlie can be deceived.

At first glance, the re-use seems difficult for Alice to implement. After all, if Alice sends a message first to Bob, Bob can check the message, and tell everyone else on the network (including Charlie) that they update their block chains. As soon as this happened, Charlie could no longer be fooled by Alice. So, most likely, only in a short period of time Alice can make repeated expenditure. Nevertheless, obviously, any such period of time is undesirable. Worse, there are methods by which Alice can make this period longer. It can, for example, use network traffic analysis to find the time when Bob and Charlie have many delays in communication. Or, perhaps, she can do something to consciously disrupt their connection. If it can slow communication even by a small amount, then this will simplify its task with a re-expenditure.

How can we solve the problem of double expenses? The obvious solution would be that when Alice sends Bob one infocoin, Bob should not try to check the deal alone. Most likely, he should broadcast a possible deal to all users of the Infocoin network, and ask them to help him determine whether the transaction is legitimate. If they all decide together that the deal is in order, then Bob can take this infocoin, and everyone will update their chain of blocks. This type of protocol can help prevent the problem of double costs, since 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 Implemented.

In more detail, let’s assume that Alice wants to give Bob one infokoin. As before, she signs the message “I, Alice, give Bob one infocoin with the serial number 1234567”, and gives the signed message to Bob. Just like before, Bob does a health check using his copy of the chain of blocks to check whether the coin is actually owned by Alice. But at that moment the protocol was changed. Bob does not just go ahead and take a deal. Instead, he sends Alice’s message to the entire network. Other members of the network check whether Alice has this infocoin. If so, they transmit the message “Yes, Alice owns infokoin 1234567, now it can be transferred to Bob.” As soon as a sufficient number of people distribute this message on the network, everyone will update their chain of blocks, which will show that infokoin 1234567 now belongs to Bob, and the transaction is completed.

This protocol has many inaccurate elements at present. For example, what does it mean to say “a sufficient number of people should broadcast this message”? What does “enough” mean? This can not mean everyone on the network, since we do not know a priori who is on the Infocoin network. For the same reason, this can not mean some fixed proportion of users on the network. We will not try to understand this right now. Instead, in the next section I will point out the serious problems in the approach that we have described. Paying attention to this problem, we will have a pleasant side effect from the creation of ideas above more understandable.

Bitcoin protocol. Proof of work

Suppose Alice wants to re-spend the protocol, which 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 an Infocoin network. As before, she tries twice to pay the same infocoin to Bob and Charlie. But when Bob and Charlie ask the network to check the transactions, Alice’s additional users will flood the network, telling Bob that they confirmed his deal, and Charlie, that they confirmed his deal by fooling one or both at the same time, accepting such a transaction.

There is a way to avoid this problem by using an idea known as proof-of-work. The idea is paradoxical and includes a combination of two other ideas: (1) (artificially) make the confirmation of transactions costly for network users in the form of computer calculations; And (2), reward them for the help of checking transactions. The award is used to ensure that people on the network try to help check transactions, despite the need to spend computing power on this process. The benefit of the fact that transaction verification requires costs, helps to avoid dependence on the number of identities (network users) controlled by someone. Thus, only the total processing power can put pressure on the test. As we will see, using some clever design, we can make it so that the fraudster needs huge computing resources for deception, which makes it practically impractical.

Here is the essence of proof of the correctness of the work. But to really understand, we must look at the details.

Suppose Alice broadcasts the news “I, Alice, give Bob one infocoin numbered 1234567”.

Hearing this message, everyone adds it to the queue of pending transactions: heard, but not yet approved by the network. For example, another network user named David may have the following queue of pending transactions:

I, Tom, give Sue an info-code, with serial number 1201174.

I, Sydney, give Cinthia one infokoin, with serial number 1295618.

I, Alice, give Bob one infocoin with the serial number 1234567.

David checks his copy of the chain of blocks, and sees that every deal is good. 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 complex computing task – proof of the correctness of the work. Without solving this problem, the rest of the network will not accept its verification of transactions.

What kind of task 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 known hash function SHA-256, but any cryptographically safe hash function is suitable. Let’s give the turn of the unfinished transactions of David label L, so that it would be more convenient for us to refer to. Suppose David adds a number x (the so-called one-time number) and calculates a 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, (output is in hexadecimal format)

H (“Hello, world! 0”) = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64

The problem that David must solve – the proof of the correctness of the job – is to find a prime number x so that when we add x to L and the result of hashing the combination starts with a series of zeros. The task can be made more or less difficult, changing the number of zeros necessary to solve this problem. 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, since the result does not start from zero. Let’s try x = 1 ,. Also will not work:

H (“Hello, world! 1”) = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8

We can continue to look for different values ​​for x = 2,3,4 …. Finally, at a value of x = 4250 we get:

H (“Hello, world! 4250”) = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

This number gives us a string of four zeros at the beginning of the hash output. This will be enough to solve the simple task of “proof of work”, but not enough to solve the more difficult task of “proof of work“.

There is a thing that makes this task difficult to solve. The result of the 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 can not be predicted. So, if we want to have a hash value of a sum with 10 zeros at the beginning, David will need, on average, to sort through the different values ​​of x before he finds a suitable simple number. This is a rather difficult task, which requires great computing power.

There is an opportunity to make this task more or less difficult to solve through a greater or lesser number of 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 problem, using a minor variation of the puzzle to prove the correctness of the work (proof-of-work) described above. Instead of requiring zeros, Bitcoin as a proof of correctness of operation requires that the hash header of the transaction block be less than or equal to the number known as the target. This goal is automatically adjusted so that the Bitcoin block occupies, on average, about ten minutes for authorization.

(In practice, there is considerable contingency in how long it takes to approve a block-sometimes a new block is approved in just a minute or two, and in other cases it can take 20 minutes or more.) This changes directly in the Bitcoin protocol, so the time Instead of solving one task, we can demand the solution of several problems, using a carefully designed software design, it is possible to significantly reduce the variance in time to test the SD unit Trees.)

Well, let’s assume that David was lucky and he found a suitable 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 then need to update their block chains to include a new block of operations in the chain.

In order for the idea of ​​proving the correctness of the work to have a chance of success, network users need an incentive to help check transactions. Without such an incentive, they have no reason to spend valuable computing power just to help check the operations of other people. And if network users are not ready to spend this power, then the entire system will not work. The solution to this problem is rewarding people who help check transactions. In particular, suppose we reward those who have successfully checked the block of transactions by enrolling a certain number of infokoins. The reward in infokoin is so great that it will give them an incentive to participate in the verification.

In the Bitcoin protocol, this confirmation process is called bincoin mining. For every block of transactions checked, a successful miner receives a reward in bitcoins. Initially, this award was established at the level of 50 bitcoins. But for every 210 thousand units tested (approximately, every four years), the reward is reduced by half. This happened only once. To date, the reward for the extraction of the block is 25 bitcoins. This rate cut will be doubled every four years until the year 2140. At that moment, the reward for bincoin mining will drop below 10 ^ -8 bitcoins per block.10 ^ -8 bitcoins, in fact, the minimum unit Bitcoin, and is known as Satoshi . Thus, in 2140 the total supply of bitcoins ceases to increase. However, this does not eliminate the incentive to continue checking transactions. Bitcoin also provides an opportunity to allocate some amount in the transaction as payment for the transaction, which will get to the miner, which helps to accept transactions. In the early days of Bitcoin, the transaction fee was zero, but with the increase in Bitcoin’s popularity, payment fees for the transaction gradually increased, and are now an additional addition to the award of 25 bitcoins for the unit’s mining.

You can think of proof of work (proof-of-work) as a competition who quickly accepts transactions. Each entry into the competition is worth a little computing power. The chance of winning a miner in a competition is (roughly speaking, with some reservations) equal to the total computing power that they control. So, for example, if the miner controls one percent of the total processing power of Bitcoin used to verify transactions, then he has about one percent chance of winning. That is, provided that the competition involves a lot of processing power, the dishonest miner will likely have a relatively small chance to distort the verification process, unless he spends a huge amount of computing resources.

Of course, while it is encouraging that the dishonest party has only a relatively small chance to spoil the chain of the block, but this is not enough to cause confidence in the currency. In particular, we have not yet finally decided the question of recurring costs.

I will analyze the double costs soon. Before doing this, I want to fill an important detail in the description of Infocoin. It would be ideal to coordinate the order in the Infocoin network, in which the transactions took place. If we do not have such an order, then at any time 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 by one, where each block contains a pointer to the immediately preceding block:

Bitcoin protocol

Sometimes, a fork appears in the chain of blocks. This can happen, for example, if two of the miners simultaneously 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 the other way:

Bitcoin protocol

It would seem that this causes a problem that we are trying to avoid – it is not clear in what order the transactions took place, and this does not clarify who owns which infokoinami. Fortunately, there is a simple idea that can be used to remove any forks. The rule is this: if a plug suddenly happens, people on the network track both forks. But at any one time, the miners only work on the continuation of that branching, in which the copy of the chain of blocks is longer.

Suppose we have a fork in which some of the miners get block A first and some of the miners get block B. Those miners who get block A first will continue to work along this branch, while the other miners will go along with branching B. Suppose , That the miners working on branching B successfully extracted the block:

Bitcoin protocol

After everyone gets the news that it happened, the miners working on the branching A will notice that branching B is now longer and will switch to work on this branch. That’s all! Immediately, the work on branching A will stop, 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 await the decision in the queues of the miners working on the branching of B, and in the future all transactions will be confirmed. In addition, it may be that the miners working on the branching of A, before it expand. In this case, the work on branching B will quickly stop, and again we have one linear chain.

Regardless of the result, this process ensures that the chain of blocks has a consistent ordering of the transaction blocks. Bitcoin accepted that a transaction is not considered confirmed before: (1) it is part of a block in a long fork, 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 order 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 twice to spend infokoyn with Bob and Charlie. One possible approach for it is to try to check out the block itself, which includes both transactions. Assuming that she has one percent of the total processing power, she can be lucky, and she confirms the block by solving the mathematical task of proof-of-work. Unfortunately, for Alice, the repeated payment will be immediately noticed by other people in the Ifnocoin 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 it broadcasts separately two transactions in which it conducts the same infocoin with Bob and Charlie, respectively. It can, for example, translate one transaction to one group of miners, and another transaction another, hoping to get approval of transactions in this way. Fortunately, in this case, as we have seen, the network will definitively confirm only one of these transactions, but not both. So, for example, Bob’s deal can ultimately be confirmed, and in this case Bob can be calm. Meanwhile, Charlie will see that his deal has not been confirmed, and he will reject Alice’s offer. So there is no problem in this. In fact, knowing that this will happen, there is no particular reason for Alice to try it.

There is another important variant of double costs, if Alice = Bob, i.e. Alice tries to pay Charlie’s coin, which she also “spends” herself (that is, giving herself). It looks so easy to notice and cope with it, but at the same time, of course, it is easy to configure several users connected to the same person or organization on the network, so this possibility must be taken into account. In that case, Alice’s strategy is to wait until Charlie takes infokoin, which will happen after the deal has been confirmed 6 times in the longest chain. She will try to fork the chain before the deal with Charlie, adding a block to which the payment transaction to herself is included:

blockchain protocol

Unfortunately, it is very difficult for Alisa to catch up with a longer branch. Other miners do not want to help her, since they will work on a longer branch. And until Alice can not solve the proof of the correctness of the work, at least as quickly as all the others in the network together – roughly speaking, this means that by controlling more than fifty percent of the processing power – it will simply lag further and further behind. Of course, she can be lucky. We can, for example, imagine a scenario in which Alice manages one percent of the processing power, but luck happens and she finds six additional blocks in a row before the rest of the network finds a new block. In this case, it could get ahead, and gain control over the chain of blocks. But this in particular event will occur with probability 1 / (100 ^ 6) = 10 ^ -12. A more general analysis in this direction shows that the probability of Alice catching up with the longer branching of the blocks is infinitesimal if she is not able to solve the proof of the 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 repeated expenses. This is just an unofficial argument of certainty. The original text representing Bitcoin, in fact, does not contain a thorough security analysis, only informal arguments on the points that I submitted. The community, who are interested in security, is still analyzing Bitcoin, and is trying to understand possible vulnerabilities. You can see some of these studies here, and I’ll mention a few problems in “Problems for the author” below (see the original test). At this point, I think it’s fair to say that the jury still does not know how safe Bitcoin is.

Ideas to prove the correctness of work and mining generate many questions. What reward is needed to convince people to mine? How will the change in the emission of infokoin affect the economy of Ifnocoin? Will Mining Infokoin ultimately concentrated in the hands of a few, or many? If there are only a few miners, will this endanger the security of the system? Presumably, the cost of transactions is balanced over time – will it lead to an undesirable source of friction, and will not small transactions be less desirable? These are all big questions that go beyond the scope of this article. I can return to these questions (in the context of Bitcoin) in future publications. At present, we will focus on understanding how 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 basically obvious modifications of Infocoin.

In order to use Bitcoin in practice, first install the wallet program on your computer. To give you an idea of ​​what this means, here is a screenshot of a wallet program called Multbit. You can see the balance of bitcoins on the left – 0.06555555 bitcoin, or about $ 70 at the rate of the day when I made this screenshot – and on the right are two recent transactions that form 0.06555555 bitcoins: How can i buy bitcoins.

Bitcoin Wallet

Suppose you are a merchant who created an online store and decided to let people pay your goods with Bitcoin. The first thing you do is generate the Bitcoin address in the program. In response, it will generate an open / private key pair, and then a public key hash to form its Bitcoin address:

Bitcoin Wallet

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 result of hashing your public key, which can be safely known in the world anyway. (I’ll return later to the question of why Bitcoin’s address is a hash, not just an open key.)

The person who will pay you generates a transaction. Let’s take a look at the data from the real deal transmitting 0.319 billion bitcoins. The following shows almost raw data. They are changed in three points: (1) the data has been converted from serial to parallel (deserialized); (2) line numbers that have been added, for ease of use; And (3) I cut various hashes and public keys, simply displaying the first six hexadecimal digits of each, when in fact they are much longer. Here’s the data:

1. {“hash”: “7c4025 …”, ”
2. “ver”: 1,
3. “vin_sz”: 1,
4. “vout_sz”: 1,
5. “lock_time”: 0,
6. “size”: 224,
7. “in”: [
8. {“prev_out”:
9. {“hash”: “2007ae …”, ”
10. “n”: 0},
11. “scriptSig”: “304502 … 042b2d …”}],
12. “out”: [
13. {“value”: “0.31900000”,
14. “scriptPubKey”: “OP_DUP OP_HASH160 a7db6f OP_EQUALVERIFY OP_CHECKSIG”}]}

Let’s go through line by line.

Line 1 contains the hash of the rest of the transaction, 7c4025 …, expressed in hexadecimal. This is used as the 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’ll talk about the deals below with a lot of inputs and conclusions, and why it’s useful.

Line 5 contains the value lock_time, which can be used to control when the transaction is completed. For most transactions Bitcoin 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 sum of money being transferred! About this further.

Lines 7 to 11 define the input bitcoins for the operation. In particular, lines 8 through 10 tell us that the input should be taken from the output from the previous transaction with the corresponding hash sum, which is expressed in hexadecimal as 2007ae … .n = 0 tells us that this will be the first output from That transaction; We will see in the near future how several conclusions (and inputs) work in the transaction, so do not worry too much about this now. Line 11 contains the signature of the person who transfers the money – 304502 …, then a space, and then the corresponding public key -04b2d …. Again in hexadecimal format.

The only thing to note about entering is the lack of an exact 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 = 0 the output from the previous transaction was 2 bitcoins, then 2 bitcoins will be spent in this transaction. This seems an uncomfortable restriction – it’s like trying to buy bread with a $ 20 bill, and not being able to break it into small banknotes. The solution, of course, must have a mechanism for obtaining the change. This can be done with the help of transactions with several inputs and outputs, which we will discuss in the next section.

The lines from 12 to 14 determine the output of bitcoins from the transaction. In particular, line 13 tells us the value of the output: 0.319 bitcoins. Line 14 is a fairly complex process. It is important to note that the value of a7db6f … is the Bitcoin address of the intended recipient of the media (written in hexadecimal format). In fact, 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 is to understand that a7db6f … is only a bitcoin address.

By the way, now it is clear how bitcoin appeals to the problem, what I “hid in my sleeve” in the last chapter: where do Bitcoin serial numbers come from? In fact, the role of the serial number is played by the hash amount of transactions. In the above transaction, for example, the receiver receives 0.319 bitcoins, which come from the first output of the previous operation with the hash sum of 2007ae … (line 9). If you go and look at the block chain for this transaction, you will see that its output comes from an earlier transaction. And so on.

There are two smart things about using transaction hash sums instead of serial numbers. First, Bitcoin does not really have any separate, permanent (virtual) “coins”. There is simply a long series of transactions in the chain of blocks. It’s a smart idea to realize that you do not need coins, and you can just do 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 the transaction.

In fact, you can continue to follow the chain of transactions further into the past. Ultimately, this process must be completed. This can happen in two ways. The first possibility will arise when you come to the very first Bitcoin transaction contained in the so-called Genesis block. This is a special transaction that does not have entries, but only a conclusion in 50 bitcoins. In other words, this transaction establishes 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 it is very similar to the deal described above.

The second option 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 Start block, each block of operations in the chain of blocks begins with a special base transaction. This is a deal – rewarding the miner who will check this block of operations. It uses a similar, but not identical, transaction format, as presented above. I will not go into the details of the format. Something I was not exact from the above, namely, what exactly is signed by the digital signature in line 11. Obviously, the payer must sign the entire transaction (except for the hash of the transaction that is generated later). At present, this is not true – some parts of the transaction are omitted. This makes certain parts of the transaction changeable, that is, they can be changed later. However, this plasticity is not included in the payout amount, senders and receivers, which can not be changed later. I have to admit, I did not 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 inputs and outputs

In the last section I described how a transaction with one input and one output works. In practice, it is often very convenient to create a bitcoin transaction with multiple inputs or multiple outputs. I’ll talk later about why this can be useful. But first let’s take a look at the actual transaction data:

1. . {“Hash”: “993830 …”, ”
2. “ver”: 1,
3. “vin_sz”: 3,
4. “vout_sz”: 2,
5. “lock_time”: 0,
6. “size”: 552,
7. “in”: [
8. {“prev_out”: {
9. “hash”: “3beabc …”, ”
10. “n”: 0},
11. “scriptSig”: “304402 … 04c7d2 …”},
12. {“prev_out”: {
13. «hash»: «fdae9b …»,
14. “n”: 0},
15. “scriptSig”: “304502 … 026e15 …”},
16. {“prev_out”: {
17. “hash”: “20c86b …”, ”
18. “n”: 1},
19. “scriptSig”: “304402 … 038a52 …”}],
20. “out”: [
21. {“value”: “0.01068000”, ”
22. “scriptPubKey”: “OP_DUP OP_HASH160 e8c306 … OP_EQUALVERIFY OP_CHECKSIG”},
23. {“value”: “4.00000000”
24. “scriptPubKey”: “OP_DUP OP_HASH160 d644e3 … OP_EQUALVERIFY OP_CHECKSIG”}]}

Let’s go through line by line. It’s very much like a transaction with one input and one output, so I’ll do it pretty quickly.

Line 1 contains the hash of the rest of the transaction. This is used as the transaction identifier.

Line 2 tells us that this is a transaction of the Bitcoin version 1 protocol.

Lines 3 and 4 tell us that the transaction has three inputs and two outputs, respectively.

Line 5 contains lock_time. As in the case of one input and one output, the value is 0, which means that the transaction is immediately terminated.

Line 6 tells us the size of the deal in bytes.

Lines 7 to 19 define the list of inputs to the transaction. Each corresponds to the conclusion from the previous Bitcoin transaction.

The first input is defined in lines 8 through 11.

In particular, lines 8 through 10 tell us that the input should be taken from the n = 0th output from the transaction with the hash value of 3beabc …. Line 11 contains a signature, then a space, and then the public key of the sender bitcoin.

Lines 12 through 15 define the second input in a format similar to lines 8 through 11. And lines 16 through 19 define the third input.

Lines 20 through 24 define a list containing two outputs from the transaction.
The first output is defined in lines 21 and 22. Line 21 tells us the value of the output of 0.01068000 bitcoins. As before, line 22 is an expression of the script language Bitcoin. The main thing that is worth paying attention to here, the line e8c30622 … is Bitcoin the address of the intended recipient of funds.

The second output is defined in lines 23 and 24 in the form similar to the first output.

One obvious oddity in this description is that although each output has an indication of the amount in bitcoin associated with it, there is no such input. Of course, the values ​​of the corresponding entries can be found by referring to the relevant conclusions in the previous transactions. In the standard Bitcoin operation, the sum of all entries in the transaction must be at least as much as the sum of all the outputs. (The only exception to this principle is the start block and the basic transactions (coinbase), both form a new offer on the Bitcoin network.) If there are more entries than leads, the excess is used as a transaction fee. This is paid to the miner for the successfully verified block, in which the current transaction is included.

That’s all about transactions with numerous inputs and outputs! They are quite simple variations 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, which belongs to me. These 0.05 bitcoins are a surrender. This is somewhat different from the process of obtaining change in the store, since the surrender in this case has a fee to itself. But the general idea is similar.

This concludes with a basic description of the basic ideas that lie in Bitcoin technology. Of course, I omitted a lot of details – we did not do a technical description. But I described the main ideas to the most common cases of using Bitcoin.

Although Bitcoin rules are simple and easy to understand, this does not mean that it is easy to understand the full implications of these rules. There is much more to say about Bitcoin, and I will explore some of these issues in the future.

I will conclude my post with an appeal to several controversial issues.

How much anonymous is Bitcoin? Many people claim that Bitcoin can be used anonymously. This statement led to the formation of markets, such as the Silk Road (Silk Road) and various successors who specialize in illegal goods. Meanwhile, the claim that Bitcoin is anonymous is a myth. The block chain is public and open, which means it is possible for everyone to see any Bitcoin transaction ever. Although Bitcoin addresses are not immediately associated with real people, computer scientists have done a great job figuring out how to de-anonymize “anonymous” social networks. The chain of blocks is an ideal goal for these methods. I will 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 achieve the recognition of guilt, but will be high enough to determine probable goals. In addition, identification will be retrospective, which means that those who bought drugs on the Silk Road market in 2011 will still be possible for identification 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 NSA and other institutions have already recognized many users. Paradoxically, Bitcoin is often presented as anonymous. This is not true. On the contrary, Bitcoin is perhaps the most open and transparent financial tool that the world has not yet seen.

Can you get rich with Bitcoin? Well, maybe. Tim O’Reilly once said: “Money, like gasoline in a car – you need to pay attention or you will end up on the roadside; But a well-lived life is not a tour of the gas station! “A lot of interest in Bitcoin comes from people whose life position is aimed at finding a really great gas station. I have to admit, I find this puzzling. In my opinion, it is much more interesting and pleasant to think about Bitcoin and other crypto-currencies 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 have a much better chance of success. How can i buy bitcoins

I omitted the details: although this post described the main ideas lying in Bitcoin, there are many details that I did not mention. Here, for example, is the feature of saving the size that is 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 knowing more if data structures are your chip. You can download and explore the original Bitcoin pages. Secondly, I’ve already talked a little bit about the Bitcoin network-questions like how the network deals with denial of service attacks, how nodes join and leave the network, and so on. It’s a fascinating topic, but it also requires a lot of detail, so I omitted it. You can learn more about this on some of the links above.

Bitcoin: 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 already seen, each 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 bitts.” But the scripting language can also be used to express much more complex transactions. In other words, Bitcoin is programmable money (forecasts about the future of bitcoin). In later publications, I will explain the scenario system, and how you can use Bitcoin scripts as a platform for experimenting with all kinds of amazing financial tools.

How not to be late in the market for crypto currency or top crowdfunding sites