In the process of discussing the mechanism of consensus for different cryptocurrencies, one problem arises, causing a number of questions. This is a lack of understanding (and definitions) regarding the security model that ensures the preservation of historical data in the registry. Although each model of consensus is theoretically aimed at preventing various attacks, it is very important to understand the objectives pursued by a single model.
Each security model has two main parts: assumptions and guarantees. If the intended input data are correct, then guarantees must also be provided at the exit from the model.
Let's delve into the security model offered by Bitcoin users that support full nodes.
In search of truth
"One of the strengths of Bitcoin - even one of the most important, in my opinion, is your ability to have a low degree of trust in others." - Peter Will
The purpose of distributed registries is to provide an orderly history of events, because in distributed systems you cannot simply trust timestamps.
When new members join the blockchain-based network, they load any available blocks and take into account every valid block sequence that is in view, starting with the hard-coded block genesis.
One of the greatest assumptions suggested by the Bitcoin security model is that most miners honestly work to support the security of the blockchain, and not vice versa. Practically, this is confirmed throughout the entire history of Bitcoin, because miners have an incentive, although the question remains whether this truth will continue in the future.
Given this assumption, the full node operators can be absolutely sure of some facts:
- No one increased the money supply except miners and in accordance with a strictly established schedule;
- No one has spent money without owning the corresponding private key;
- No one has spent the same money twice.
Full node operators may well be certain of some other assertions. There are reasonable guarantees that:
- Any block in the circuit was created within a two-hour period relative to the time stamp of the block itself;
- They synchronize the true version of the blockchain history.
At the technical level, this will require many checks.
All blocks follow the rules of consensus:
- Each block is associated with a parent block;
- Each unit corresponds to its degree of complexity and substantial work has been expended on its solution;
- Block timestamps are within the time window for newly found blocks;
- The Merkle root (hash of the hash of each transaction in the block) corresponds to all transactions in the block;
- None of the blocks exceeds the maximum size allowed;
- The first (and only the first) transaction of each block is a coinbase transaction (a special type of transaction that does not require previously existing exits, that is, the reward that miners receive for extracting new blocks);
- Coinbase outputs pay no more than the currently established reward for the found block;
- Blocks contain only valid signatures.
All transactions follow the rules of consensus:
- Input and output values are valid;
- Transactions only spend unspent exits;
- All entries spent have valid signatures;
- None of the transactions Coinbase exits were spent before the 100 blocks found since their creation (maturation of coins received by miners);
- None of the transactions spent inputs in the unconfirmed state, that is, prior to its inclusion in the block.
There are also many other rules that will take too long to discuss here.
Safety thermodynamics
Once the transaction in the block is confirmed, it cannot be canceled without a minimum expenditure of energy for rewriting the chain.
“Bitcoin’s Security Model Revisited” by Yonatan Sompolinsky1 and Aviv Zohar
As long as none of the attackers have computational power exceeding the network’s capacity by 50% and honest nodes can quickly communicate with each other, the probability of a transaction being canceled decreases exponentially along with an increase in the number of confirmations of this transaction. There are other types of attacks, such as selfish mining, which can reduce the required amount of power, however, they are quite difficult to implement.
Considering the current amount of work produced by Bitcoin miners, it can be argued that approximately 1026 hashes will be needed to create an alternative blockchain directly from the genesis block with increased evidence of the work done so that full nodes accept it as a true block chain.
Let's analyze some price indicators of such an attack:
Antminer S9 requires 0.1 joules per Gh / s (109 hashes)
1026 hashes * 0.1 J / 109 hashes = 1015 joules
1015 joules = 2,777,777,778 sq / h * $ 0.10 sq / h = $ 277,777,778 will be the cost of electricity for rewriting the entire blockchain.
At the time of this writing, the complexity of a single block tends to 253,618,246,641, which would require approximately:
253,618,246,641 * 248/65535 = 1.09 * 1021 hashes.
1.09 * 1021 hashes * 0.1 J / 109 hashes = 1.09 * 1011 joules
1.09 * 1011 joules = 30.278 kW / h * $ 0.10 kW / h = $ 3,028 electricity cost for rewriting one block.
That is why we can conclusively assert that Bitcoin is thermodynamically safe.
To reduce costs, you can change some of the variables in the above calculations, but we can be sure that we will need many millions of dollars in electricity to rewrite the entire boxchain. However, an attacker with such a hashing capacity can, in the worst case, rewrite transactions until 2014, and we will soon consider the reason for this possibility.
Also note that this calculation does not take into account the cost of owning and using the necessary amount of mining equipment to conduct this type of attack.
Sybil resistance to attacks
Since the Bitcoin protocol considers that the true chain is the one with the most cumulative proof of operation (and not the longest chain, as often incorrectly indicated), as a result of a new peer joining the network, you only need to connect to one fair peer to find the true .
This is also known as "Sybil resistance", meaning that it is impossible to attack a node, creating many dishonest peers that give false information.
The figure shows the worst-case scenario in which your node is subjected to a massive Sybil attack, but still has one connection to an honest node that is connected to a true Bitcoin network. As long as one honest feast sends true blockchain data to your full node, it will be perfectly clear that some Sybil intruders are trying to deceive you, and your node will ignore them.
Real time consensus
The bitcoin protocol creates a number of other interesting attributes with respect to maintaining a network-wide consensus when your node is on the advanced blockchain.
The authors of “Research Perspectives and Challenges for Bitcoin and Cryptocurrencies” note the following properties that are important for the stability of cryptocurrency:
Final consensus. At any time, all compatible nodes agree on the prefix of what becomes a possible “true” blockchain.
Exponential convergence. The branch probability for depth n is O (2 − n). This gives users high confidence that the simple rule of “k confirmations” will ensure the immutability of completed transactions.
Vitality. New blocks and reliable transactions with adequate commissions will continue to be added to the blockchain for a reasonable period of time.
Right. All units in the chain with the greatest proof of workload will include only valid transactions.
Justice. A miner owning X% of the total network computing power will extract approximately X% of blocks.
The authors of the article note that Bitcoin seems to have these properties, at least under the assumption that most miners remain honest, and they will be stimulated by the reward for the found block obtained in providing proof of the amount of work done (Proof of Work).
There are many other algorithms that can be used to maintain consensus in distributed systems, for example:
- Proof of ownership
- Proof of coin age
- Proof of deposit
- Proof of destruction
- Proof of activity
- Proof of past tense costs
- Federative Consensus
- Practical Byzantine Fault Tolerance.
These algorithms create different security models — the most obvious difference from the proof of work is that the consensus of each of the alternative systems is achieved through internal resources (coins or reputation) rather than external resources (electricity). This creates a completely different set of incentives for validators (and trust) in the network, which dramatically changes the security model.
Misunderstanding of security model
There is a common erroneous assumption that Bitcoin has a well-defined security model.
In fact, the Bitcoin protocol was built and built without a formally defined specification or security model. The best we can do is to study the incentives and behavior of the participants in the system in order to better understand and try to describe it.
However, there are several properties of the Bitcoin protocol that are often analyzed incorrectly.
Some blockchains were badly hit by attacks when developers added centrally translated signed checkpoints to the host software, essentially claiming that “block X was tested by developers as being in the correct historical chain.” This is a model of absolute centralization.
It is worth noting that bitcoin has 13 hard-coded control points, but they do not change the security model in the way that centrally broadcast control points do. The last control point was added to Bitcoin Core 0.9.3 and is located at block 295000, which was created on April 9, 2014. This block had a complexity of 6,119,726,089, which would require approximately:
6,119,726,089 * 248/65535 = 2.62 * 1019 hashes
2.62 * 1019 hashes * 0.1 J / 109 hashes = 2.62 * 109 joules
2.62 * 109 joules = 728 kW / hour * $ 0.10 kW / hour = $ 73 amount for block generation.
Thus, if Sybil the attacker completely surrounded the new node, which synchronized from scratch, he could create several short blockchains with a small number of blocks almost for free, but only up to some control blocks.
If an attacker cuts off a node from the network while it is synchronized to block 295000, then the attacker will be able to give him false blocks, spending $ 73 on one block, until he finally reaches the point of recalculation of complexity. However, in the process of further synchronization of the attacked node, the costs for supporting the chain with an increased total volume of work performed will constantly increase for the attacker.
Greg Maxwell and Peter Will together stated that they hope to someday remove the control points completely. Bitcoin Core Lead Specialist Vladimir van der Laan noted that control points are a constant source of confusion for people who want to understand the Bitcoin security model.
An argument can be made that the full node “trusts” Bitcoin Core developers regarding the reality of the blockchain history until April 9, 2014, but the node still checks Merkle hashes in the header of each block, which means that the reliability of the transaction history is still provided proof of work performed. These old checkpoints allow for increased performance (skipping signature verification) during the initial synchronization of the blockchain, although the introduction of libsecp256k1 made the performance difference less significant.
Control points remain involved for three purposes:
Preventing the filling of nodes with acceptable memory, but not corresponding to the complexity (low) headers of the blocks found.
Skipping signatures in previous blocks (increased performance).
Evaluation of synchronization progress.
While this article was being written, Greg Maxwell proposed replacing control points with cumulative testing. Once a node is configured on a chain that contains more than 5.4 * 1024 hashes, chains with less cumulative work will be considered invalid. This roughly coincides with the volume of work performed up to the block of 320,000 in September 2014, and at that time the complexity of the individual blocks was approximately 27,000,000,000.
Mining blocks of 27,000,000,000 will require approximately
27,000,000,000 * 248/65535 = 1.16 * 1020 hashes
1.16 * 1020 hashes * 0.1 J / 109 hashes = 1.16 * 1010 joules
1.16 * 1010 joules = 3.222 kW / h * $ 0.10 kW / h = $ 322 per unit
Thus, given the proposed change, if the Sybil-attacker completely surrounded the new node, which synchronized from scratch, he could issue him false blocks, starting with any block after the genesis of the block, almost without spending money. If Sybil the attacker completely surrounded the node, which synchronized approximately from the block of 320 000, he can start giving him a false chain from this point at a price of 322 dollars per block.
In other words, an attack at the time of the initial synchronization of a node is relatively inexpensive, if an attacker can gain complete control over the Internet connection of the attacked node, otherwise the node will easily reject the attacker's fake blocks.
Add to the above that each Blockchain system has its own genesis block, hard-coded into the node software. You can argue that there is a social contract with a “common history”, which is a distributed registry, i.e. as soon as the block is old enough, an understanding emerges among all the participants in the network that it can never be changed. Thus, when developers take a very old block and create a control point from it, this is done on the basis of a validation agreement, and not under the dictates of history.
In addition to control points, there is also the question of how the node loads itself. The current process for Bitcoin nodes is to check if it has a local database of peers that he knew about before. If not, he will request a set of “DNS seeds” that are hardcoded into the software. These seeds contain a list of well-connected Bitcoin nodes that are uploaded to your site.
As we can see from the Bitcoin Core 0.13 code, the currently active DNS seeds are supported by Peter Will, Matt Corallo, Luke Dushr, Christian Decker, Jeff Garzik and Jonas Snelli. Anyone can maintain seeds on the DNS network using Peter Wiel's bitcoin-seeder software or Matt Coral software, although in order to be accepted by new hosts, you need to convince the developers of one of the complete host implementations to add your DNS host to their software.
This may again seem like a point of absolute centralization, when the boot process for a new node depends on only six seeds of the DNS. Recall that the Bitcoin security model requires connecting to only one fair feast to counter Sybil attacks.
Thus, the new site should only be able to connect to one DNS seed that is not compromised and returns the IP addresses of the honest nodes. However, there is a backup option, if for some reason all the seeds of DNS are unavailable - this is a hard-coded list of trusted IP addresses of the nodes, which is updated for each release.
The security model for various initialization parameters is not that the full node operator trusts DNS seeds from X or Y kernel developers to give them honest data, but that at least 1 / x DNS seeds are not compromised or 1 / y Core developers are honest about reviewing approved changes to a list of hard-programmed peers.
Nothing is absolutely safe.
At a deeper level, when you run a full site, you trust to a certain extent the hardware and software you are working with.
There are methods for verifying software by comparing digital signatures of your binary file with van der Laan signatures, but it is unlikely that many people will attend to such verification. As for reliable equipment, this is a difficult problem. Most likely, you will use a secure hardware solution like ORWL, which is guaranteed to “self-destruct” when trying to interfere.
However, given that hardware architectures for processors, RAM, and other important hardware are usually proprietary, you can never be 100% sure that they are not compromised.
The balance of power in Bitcoin
The water becomes even more turbid when you start exploring the relationships between the various participants in the system.
The goal of running a full site is to protect your financial sovereignty. As a rule, this means that when you install and run a certain version of the software, you enter into an agreement that you will comply with the rules of this software and that everyone who uses the network must also comply with them.
So, if people want to change the rules so that they are not backward compatible, you must explicitly agree to changing these rules by launching a new version of the software. On the other hand, backward compatible rule changes can be implemented and applied without your consent.
A simplified description of the dynamics of the forces of influence in Bitcoin:
It is important to note that full site software is not automatically updated, and this is intentional. Automatic updates significantly shift the balance of power towards the developers, allowing them to forcefully change the rules on the nodes and miners without permission.
Unfortunately, while the rule change may be technically backward compatible, over the years we have learned that sufficiently innovative software forks can actually implement changes that are clearly beyond the scope of the previous version of the rules. Vitaly Buterin demonstrated this with a description of the soft-fork method for the time of the emergence of new Bitcoin blocks instead of 10 to 2 minutes, which, of course, will speed up the emission schedule of new bitcoins.
There is one trump card that full knots have in order to fend off unwanted soft forks - to go into hard fork from miners who have implemented soft fork. This is difficult and raises many questions about the degree of consensus and the search for economically important nodes.
Technically, this can be done by changing the miner's algorithm from double SHA256 to another hash function, thereby making all the SHA256 asics useless for mining Bitcoins. It is for this reason that node operators must remain vigilant about changes in the ecosystem and remind miners that they can be replaced if they exceed their authority.
Game theory is largely present when discussing mining operations and their security threats to Bitcoin, and I reflected in a previous article about how the mining ecosystem can change. While Bitcoin mining is more centralized than most of us would like, it still works well because bitcoin miners invest a lot of capital - they cannot risk and destroy their investments, acting maliciously in the system being monitored .
SPV Security
Many Bitcoin users use a lightweight client to access the network, rather than a full host, since it requires far fewer resources while providing sufficient security.
A customer using simplified payment verification (SPV) downloads a complete copy of the headers for all blocks in the entire chain. This means that the load and storage requirements are scaled linearly with the amount of time since Bitcoin's invention. This is described in section 8 of the whitepaper Bitcoin.
Satoshi wrote that the SPV client “cannot verify the transaction independently, but by associating it with a certain place in the chain, he can see that the network node has accepted it, and the blocks added after it, only confirm that the transaction has been accepted by the network”. SPV assumes that further blocking of transaction X will be expensive.
The SPV appears to offer security guarantees similar to those provided by full nodes, but with the additional assumption that any block with a valid title and proof of operation always contains valid transactions. Since SPV clients do not check all the consensus rules described in the first section of this article, they assume that the consensus rules are checked by the nodes from which they request transactions.
Additional, insignificant differences affect peers hiding information from you. When your full site is running, peers can hide unconfirmed transactions and blocks from you. However, as soon as you receive a block from any other peer, no one can hide from you the transactions that are in this block. On the other hand, PIR can provide the SPV client with a block header, and then hide the transaction information in this block.
SPV clients can make a request to find out information about transactions involving certain addresses. Although it would be quite expensive for peers to lie about the existence of fake confirmed transactions (you need to mine the block with enough PoW), they can lie, claiming that there are no results for the bloom filter used to query the transaction information. It is also worth noting that SPV is seriously vulnerable from the point of view of privacy due to defects in bloom filters.
BitcoinJ has an excellent description of the SPV security model. With regards to unconfirmed transactions noted:
“In SPV mode, the only reason you can trust the authenticity of a transaction is the fact that the transaction has been translated by the nodes to which you are connected. If an attacker could convince you that you are connected to his nodes, this meant that he could force you to accept a completely invalid transaction (spent non-existent money), and it would still be accepted as if it were real. ”
The security of an SPV is probably “good enough” for the average user, although it can be improved with evidence of an SPV fraud. A discussion was held on this concept, but the proposals for their inclusion in the protocol were not implemented.
There is no place like Localhost
If you do not operate a full node (and in fact do not use it to verify transactions), you outsource at least some level of trust to third parties, which leads to a different security model for your Bitcoin use. Please note that this does not necessarily require that all users and companies create their software directly on top of the Bitcoin Core RPC API.
Some alternative infrastructure configurations may use the following options, but are not limited to them:
1) Use a mobile wallet, such as a Bitcoin Wallet for Android, GreenAddress or Stash, which allow you to configure the wallet to execute requests only from your own full site.
2) Create applications based on SPV node libraries, such as BitcoinJ, and configure them to connect only to your own full nodes. In BitcoinJ, this can be done by defining your own SeedPeers, which you transmit to your group of peers during initialization. With libbitcoin, you can set up a network connection to a specific host using this example.
3) Creating a proxy server that is compatible with the Bitcoin Core JSON-RPC API, which sends some calls to third-party services, but also automatically checks the data returned by them, making requests to the local full site. For an example, see BitGo’s BitGoD software. This hybrid model is able to provide the best of both worlds: you can use advanced features provided by third parties, while maintaining your financial sovereignty.
Full knots for freedom
It is clear that operating on your own full node provides excellent security with the fewest necessary assumptions. Considering that you can build a computer that can reliably work with a complete node for only a few hundred dollars, make a calculation and determine whether it is worth protecting your financial sovereignty.
