LITMIR.BIZ

Скачать книгу

      Verifying the transaction

      The first thing the node does when receiving the transaction is to use the public key to decrypt the message so that it can read it. It must then verify the transaction. This process ensures that the transaction is valid, based on a number of different criteria. We won’t go into all the details, but essentially the node asks itself (and answers) questions like these:

       Is the message properly structured and not exceeding the maximum message size?

       Does the message contain valid information — for example, does it contain valid input and output addresses and sums, within valid ranges, assigned to the addresses?

       Does the input address exist in the blockchain with a valid balance?

       Is a sufficient transaction fee associated with the transaction?

       Does the wallet sending the transaction have a right to send the transaction — that is, is the public key sent with the message associated with the address from which the cryptocurrency is being sent?

What happens if the message is not valid in some way? The node throws it away because there’s no point sending it on to the next node. But if it’s valid, the node adds it to a pool of valid transactions (a memory pool or mempool), and sends it to other nodes on the network. These other nodes will do the same: decrypt and verify the transaction and add to their mempool if they find it valid. (That’s part of the consensus process, ensuring that everyone agrees.) Thus the message, in a matter of seconds, propagates (spreads) across the crypto network, being picked up by node after node.

      

So the mempool is a collection of transactions waiting to be confirmed, solidified, and included into a block. The size of the mempool ebbs and flows depending on the current number of transactions hitting the network, and, of course, as the network congestion goes up, transaction fees go up. (You can find a very useful site for inspecting the current backlog of transactions in the mempool and current transaction fees at https://jochen-hoenicke.de/queue/#0,all.)

      Some nodes are mining nodes. These nodes add blocks to the blockchain, in a competition to earn Bitcoin. These nodes are also creating memory pools, collections of transactions that need to be added to the blockchain.

      Competing for Bitcoin, the ten-minute contest

      Here’s how the mining competition works. We’ll begin at the point at which a miner has just won the right to add a block to the blockchain. When this happens, the winner sends the winning block out across the network, and it gets picked up by the nodes and added to their versions of the blockchain. That’s when the next competition begins.

      

Each round of this game is designed to last around ten minutes; remember, one purpose of mining is to dribble new Bitcoin into the blockchain at a set rate; currently 12.5 Bitcoin every ten minutes. On average, a miner will succeed at the game every ten minutes, will be rewarded cryptocurrency, and the game restarts.

      A miner receiving the new block first compares the block to the miner’s mempool and removes transactions from the mempool that have been added to the latest block, leaving only transactions that have not yet been added to the blockchain.

      The miner then gathers together transactions from the mempool into a new block, which is known as a candidate block. This block can be added to the blockchain, if the miner can win the competition.

      HASHING?

      A hash is a long number that is a kind of fingerprint for a set of data. That data, when passed through the same hashing algorithm, will always produce the same hash, and that hash cannot match any other set of data. The hash identifies the data uniquely. For more on hashing, see Chapter 2.

The miner creates a block header for the block, which includes a timestamp, a software version number, the hash of the previous block, and the hash of the block’s transaction’s Merkle tree root (never mind, you don’t have to know about Merkle trees). The block header contains another couple of things that are related to the game that the miner has to play to compete against the other miners.

      So now thousands of mining computers around the world that have created candidate blocks of data — records of transactions — are eager to add their own blocks to the blockchain. So the system has a choice to make: Which block, from which miner, will be added to the blockchain? That decision is based on a combination of chance and computing power. The Bitcoin network uses something called a proof of work task. All the miners are given the same task to undertake, and the first one to accomplish it wins, adds their block to the blockchain, and takes home the block reward: the combined transaction fees and block subsidy.

      A Proof of Work task can be almost anything, as long as it is a complex task that takes a more or less predictable amount of work and results in an answer that is quickly and easily verifiable.

      Primecoin, for example, has a Proof of Work task that involves finding chains of prime numbers that are then stored in the blockchain and available for use by mathematicians for, well, whatever it is they do with prime numbers. In the case of Bitcoin, the Proof of Work task has no practical use beyond securing transactions in the blockchain. Here’s how Bitcoin’s Proof of Work task functions.

      The miner is looking for a number that matches a particular criteria; it must be a number that is below a certain target level (that target is one of the items stored in the block header).

      The number is created by hashing the block header, creating in effect a digital fingerprint. (For more on hashing, see Chapter 1).

      Now, the hash is a 256-digit binary number, expressed as a 64-digit hexadecimal number. Here’s an example:

       000000000000000015ecd7feb009048fb636a18b9c08197b7c7e194ce81361e9

      Each block has a target number. The hash of the block header has to be equal to or less than the target number. Look at the preceding hash. It starts with 16 zeros and is actually a winning hash from some time ago. The more zeros at the start of the number, the smaller the number, and the harder to find, and over time difficulty typically goes up. Now, the target number is even smaller (this example, with 16 zeros at the start, is from some time ago). It begins, at the time of writing, with 19 zeroes.

      The smaller the target number, the harder the task, right? Because fewer numbers are below a small number than a large number, and we need a hash that is less than the target.

      So the miner hashes the block header. But every time you hash a piece of data, you’re going to get the same result, right? So if the miner hashes the block header and finds that it’s not less than the target, they have to change the block header. Well, the nonce is a piece of data in the block header. It is simply a number. The miner changes the nonce and hashes again. This time, the result of the hash will be different. Chances are, it’s still not less than the target number, so the miner changes the nonce, hashes again, and checks the number, and so on.

      Now, the magic of the hashing algorithm is that you can’t predict which nonce will get you the result you want. The only way to find the result you want is to try, and try, and try again — thousands of times — until you get a hash that is less than the target. And if you do this before anyone else, you win!

      This task is hugely difficult. A 64-digit hexadecimal number has this many possible variations (whatever this number is called!): 39,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000.

Скачать книгу