Gearfuse Technology, Science, Culture & More
In part one we were talking about Transactions, temporary marking server and the proof of work model. Now let’s dive deeper into the Bitcoin’s network, different types of transactions and how the network verifies the payments. More and more vendors accept cryptocurrencies and with the big players from Gambling industry switching to cryptocurrencies, anything from a typical sites offering traditional casino games to sites like Sportsbet where you can bet on any sport you can imagine using our precious BTC. Keep in mind that the number of sites like that will grow tremendously and many big players in the gambling industry are openly telling that Cryptogambling is the future. Thanks to the blockchain technology and the anonymity it gives of course. Now they can ignore national anti-gambling laws. To understand that we need to learn how both the Network and Verification of payments work. Take a cup of a good coffee and enjoy the read! If you haven’t read part one, you can find it here
The Network
The step-by-step operation of the network is as follows:
1) New transactions are advertised to all nodes
2) Each node collects all transactions into a single block.
3) Each node works on finding a complicated proof of work for its block.
4) When a node finds evidence, it announces the block to all nodes.
5) Nodes accept a block only if all transactions contained there are authentic and haven’t been previously executed.
6) Nodes express their acceptance of the block and they start the work on the next block, using the accepted block hash as the previous block hash.
Nodes always consider the longest chain to be the right one, continuing to work on extending it. If two nodes distribute two versions of the next block at the same time, each node will receive both versions in different order at specified intervals. In such a case, they will always work on the first which they received, but they will keep the second branch in case that one would become longer. The node is torn off when the next proof of the work done is found, which extends one of the branches. The nodes that worked on the wrong branch will switch to the longer branch.
Information on the occurrence of new transactions does not necessarily have to reach all nodes. It is enough to reach a sufficiently large number of knots. In this case, they will also get to the block in a short time. The transmission of blocks is also resistant to the possibility of non-delivery of messages. If a node does not receive a block, it will ask for it when it receives the next block, realizing that one has been missed by it.
2. Incentives
According to the assumption that the first transaction in the block is a special kind of transaction which creates a new coi, belonging to the creator of the broken block. This provides an incentive, an incentive for the other nodes to support the network and the possibility of an initial distribution of coins for circulation, as the model doesn’t recognise the central authority that would issue them. The steady increase in the volume of new coins is analogous to that of former gold miners who are exploiting ever deeper resources, thus adding new amounts of gold to the circulation. In our case, the operating depth is based on increasing the consumption of computing time of the processor and energy.
Incentives can also be found in transaction fees. If the underlying value of a transaction is less than its input value, the difference is the transaction fee paid as an additional reward, making up the total amount of rewards for breaking the block containing that transaction. As soon as a top-down number of coins in circulation is reached, the incentive can be channelled entirely towards transaction fees, being completely inflation-resistant.
Motivation of this type may help to encourage nodes to function properly. If a greedy attacker is able to accumulate more processing power than all “fair” nodes, he’ll have to choose between using this to steal BTC from a person by stealing his payments again or using it to generate new coins. As a result, he should come to the conclusion that it is more cost-effective to proceed according to the rules. Rules that reward him with more coins than anyone and anything else. He should also realise that it’s unprofitable to undermine the entire system, and thus its credibility – and thus also the value of his own assets.
3. Disc Space Recovery
When the last transaction is covered by a sufficient number of blocks, the transactions in front of it can be deleted to save disk space. In order to achieve this without violating the hash belonging to a block, transactions are hashed according to the merkle tree, where only the root is attached to the hash of the block. Old blocks can be compressed by cutting off the tree branches. There is no need to store internal hashes.
The header of a zero transaction block should take about 80 bytes. If we assume that blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. Considering the computer sets typically sold with 2 gigabytes of RAM (2008 status) and Moore’s Law, assuming an increase of 1.2 GB per year, the amount of disk space shouldn’t be a problem, even if the block headers will have to be stored in the memory.
4. Simplified Verification of Payments
It’s possible to verify payments without the need to launch the entire network of nodes. You only need to keep a copy of the block headers of the longest chain as a evidence of the work done, which you can obtain by sending queries to network nodes until you are convinced that you have the longest representation of the chain, and then acquire the branch of the merkel tree in which the transaction is marked with a timestamp. The user cannot verify a transaction on his own, but by connecting it to a place in the chain. The user is able to state that the transaction has been accepted by the network of nodes, and blocks added after it confirm even more strongly that it has been accepted by the network.
In this form, verification is reliable as long as “fair” nodes have control over the network, but it can become more unreliable if the network starts to be dominated by the attacker. While nodes belonging to the network can verify the legality of transactions themselves, the simplified verification method can be cheated through fabricated transactions originating from the attacker, propagated as long as the attacker manages to maintain control over the network. One strategy to combat this type of attack is to receive notifications from network nodes when they detect the wrong block, thereby prompting the user’s software to download a full block with transactions marked as alarming to confirm inconsistency. Companies receiving frequent payments will probably prefer to have their own nodes for more independent security and faster verification.
Read more in part 3!
