Part Five: How Bitcoin Works – Bitcoin Network
How Bitcoin Works – Bitcoin Network . So far we have learned together how transactions can be published and incorporated into Blockchain. This process occurs through the Bitcoin network. The Bitcoin network, as already known, is a peer-to-peer network. Peer-to-peer networks can also be used for many other purposes, not just as used in Bitcoin. In the fifth discussion of How Bitcoin Works – This Bitcoin Network, we discuss more specifically on how Bitcoin works in Bitcoin tissue.
The nodes in Bitcoin are all the same. There is no hierarchy, no special node nor function as the parent node. The Bitcoin network runs through TCP and has a random typology. Each new node, can be directly joined to the network whenever he wants. Everyone can download Bitcoin Applications, install, and then run from your laptop or desktop computer.All incorporated and connected in the Bitcoin network, have the same rights and capabilities.
Bitcoin networks often change over time, and are quite dynamic, because there are nodes coming in, and there are nodes coming out of the network. There is no way that can explicitly explain why the node left the network. If one node can not hear the publication of a transaction in some time, it is established in approximately three hours, as the duration for the hardcode process to the client in general. Being, another node will start to forget it.In this way, the network can handle the node that will depart fromline. So this time lag can be useful over the entry of the nodes in the network.
Nodes connect to peer at random. But there is no geographical topology whatsoever. That is, suppose now you run a new node and want to join into the network. Then start with a simple message to one node you already know. This is usually called the seed node .Usually, there are several ways to see the list of seed nodes, so you can get in touch with each other specifically.
Suppose you are sending a message like this, “Say the address of another node you know”.And you can repeat sending this message to new incoming node. Then, you can choose which node you will contact. So you become a fully functioning member of Bitcoin network.
There are several ways you can see nodes randomly. Ideally it will produce one node that can be viewed in such a random manner. When the node joins into the network, one thing to know is how the node is to be able to make contact with one of the other nodes that have been in the network before you.
The function of this network, is to keep Blockchain. In publishing transactions, all nodes in the network need to listen to the transaction’s verification. This process occurs through a simple flooding algorithm called the gossip protocol. Why through flooding algorithm (flood arithmetic) ? Because basically the nodes in the network will listen to the publication of transactions that are so much happening in the Bitcoin network. And this flooding algorithm is an algorithm that serves to distribute transaction material to be published in Bitcoin network.
For example like this, suppose Nita want malakukan payment to Rudi. The client and node send the transaction to all nodes that have been connected with it. Then, each node will execute a series of checks to determine whether the transaction is received and forwarded.If the check is successful, then the node will send to all its node partners.
If any node hears a transaction but has not logged into Blockchain, the node will place the transaction into the transaction pool. But there is no need to broadcast it. This is done to ensure the flooding protocol has actually ended first. So the transaction does not looparound the network. Each transaction can be uniquely identified on its hash. So it will be easier to find transactions in the pool of transactions.
Then how does the node when deciding whether the transaction should be disseminated or not? Previously, there were four checks required when validating a transaction.
- The transaction must be valid with its block chain. Then the node runs the script on every output in the previous transaction that has been redeemed. And make sure the script runs correctly.
- Check that the output that has been redeemed in the previous transaction has not been spent or issued.
- Will not relay transactions that have been seen or heard. (as in the example on transactions that have been placed in the transaction pool)
- Node will only accept and relay “standard” scripts based on scripts that are in the list only (whitelist script) .
All of these checks are reasonable checks of their nature. And all nodes should apply this to keep the network up and running properly. Although basically there is no specific rule that the node should run this step. Because the Bitcoin network is peer-to-peer. Everyone can join it. The possibilities of a double spend node are always there.
Sometimes, the node must also perform this check for itself. Because these possibilities are always there. So it is possible that there will be different views on pending transactions, but has been placed in the pool of transactions.
If anyone tries to double spend, it becomes quite interesting. Because eventually there will be differences that view earlier. Suppose that in this example, Nita tries to pay the same coins to Rudi and Anton. Then send the coins to both people simultaneously. Some nodes will hear Nita transactions to Rudi first. While other nodes hear the transaction Nita to Anton first.
When a node hears one of those transactions, then adds them to the transaction pool.Meanwhile, if you hear about other transactions, it will see a double spend . Then the node drops the last transaction, and does not relay the transaction or enter into the transaction pool. As a result, the node does not approve the transaction to be added to the next block.This situation is called a race condition .
The good news, this process can work well to overcome double spend . So whoever the miners who will mine the next block, must determine one of the two pending transactions.Which transactions will be included in the block permanently.
We see in this example, in one of Nita’s transactions to Anton that is expected to enter into the next block. When the node viewing the Nita transaction to Rudi sees this other transaction (Nita to Anton), the node will drop this transaction from the transaction pool because it has been viewed as a double spend . While the node that heard the block with the transaction Nita to Anton, will remove the transaction from the transaction pool pool.Because a valid transaction on this has been entered into the blockchain. So there will be no disagreement if once this block has spread to the Bitcoin network.
Generally node behavior depends on what they first heard. This will position transactions within the network. If two different or conflicting transactions are announced on two different network positions, then they will begin to overwhelm the entire Bitcoin network.Which transactions a node sees first depends on where it is in the Bitcoin network.
The assumption, that all nodes will apply this, that is still based on whatever he sees first.Since there is no centralized authority that makes nodes have to run this, the nodes are also free to implement other desired logic. In terms of choosing one of the two conflicting transactions.
Well, so far we have seen how the transaction proceeds. In announcing new blocks, the process is the same as with the spread of a new transaction. It also depends on the same race condition . If two blocks are mined at the same time, there will only be one block to be inserted. Which blocks of the two will be included, depending on which block is one of the blocks, built on it by another node. Then the other block would be an orphan block.
Meanwhile, to validate a block, it is more complex than to validate a transaction. Because in addition to providing validation to the header and ensuring acceptable hash values, the node must also validate every transaction contained within the block.
The node will simply forward the block on which the block is again built by another node, on the longest branch in the block chain. This is to avoid development of forks . There are similarities in transaction validation, nodes can also implement different logic. Node may relay invalid blocks. Or it will also relay blocks built outside the starting point in the block chain. Although this will lead to the development of fork, but no problem. Because the protocol in block validation is designed to be able to withstand something like this.
Bitcoin Network Size
Basically, it is quite difficult to measure the size of the network in Bitcoin. Because as has been said at the beginning, that the network is quite dynamic, and there is no central authority in it. There are researchers who say that the network has a million IP addresses in a given month as a node Bitcoin node. Then there are those who see only about 5,000 to 10,000 nodes permanently connected in the Bitcoin network. And the nodes fully validate every transaction they hear.
Full Node and Storage Space
Full node, must remain permanently connected in the network. So it can hear the whole data. The longer the node ofline, the more the need to capture the data that must be done when re-connected into the network. In addition, the node must also store the entire block chain and require a good network connection. Of course to be able to hear every new transaction and forward it to other nodes. The need for this storage space is currently gigabytes.
Full nodes must also maintain the overall output of unused or spent transactions, on coins that can and are available for purchase. Ideally, this will be stored in RAM. So after hearing of new proposed transactions in the network, nodes can quickly see the output of transactions to be claimed. Then run the script, see if the signature on the transaction is valid, then add the transaction into the transaction pool.
Quite different from the full node, on lightweight node (light node) is also called thin clients,or Simple Payment Verification (SPV) . Most of the nodes in the Bitcoin network are the lightest nodes. Light nodes differ completely with full nodes . The difference is, because this light node does not store the entire block chain. They only keep small pieces, which they need to verify certain transactions they care about.
Simply, this lightweight node example can be seen when we use Bitcoin wallet. Because it will usually combine SPV node. This node downloads block headers and transactions representing payments to the address you use.
This SPV node does not have the same level of security as the full node. Since the SPV node has been able to download the block header, it can be used to check whether the block is sullit to be mined or not. But can not to see every transaction entered into a valid block.Because they do not store transaction history, nor do they know a series of output transactions that have not been spent.
The SPV node can only validate related transactions and will affect their transactions only.So basically, this node entrusted to the full node to validate all other transactions that occur within the network.
The assumption is that there are full nodes that will be able to work hard, and if the miners find it difficult to mine this block, which is basically a costly process, they may also do some validation to ensure that this block will not be rejected.
To become a SPV node this means it has made great cost savings. Because it does not require good connections, large storage space up to gigabytes, adequate devices such as on full node. Whereas, the block header required light node is only 1 / 1000th the size of the blockchain size. So, to save it only takes tens of megabytes.
So, discuss our discussion on the fifth part How Bitcoin Works – Bitcoin Network this time. This long discussion, has discussed how the whole transaction process in the network, how the transaction validation, as well as on a new block. In addition, it has been discussed also with regard to network size, storage space, and full node and lightweight node in Bitcoin network.