(Continued) Misunderstandings of the Security Model
In addition, every blockchain system hardcodes the genesis block into the node software. You might think that “shared history” (ie, ledger) is a social contract-once a block has a long enough history, all participants in the network will reach a consensus that this block will never be Will be rolled back. When a developer selects an early mined block and uses it to create a checkpoint, it is more of a recognized integrity check than an objective description of history.
In addition to checkpoints, how the node implements self-guidance is also a problem. At present, the self-booting process of Bitcoin nodes is to check whether the node has stored locally the data previously learned from peer nodes. If not, the node will query a set of “DNS seeds” that are hard-coded into the software. These seeds are responsible for maintaining a list of well-connected Bitcoin nodes and returning this list to your node.
As we can see from the code, Bitcoin Core 0.13 currently uses DNS seeds run by Pieter Wuille, Matt Corallo, Luke Dashjr, Christian Decker, Jeff Garzik, and Jonas Schnelli. Anyone can use Pieter Wuille’s Bitcoin seed generator software or Matt Corallo’s software to run DNS seeds. However, they must persuade the developer of a full node implementation to add their DNS seed host to the other’s software.
The boot process of new nodes only relies on 6 DNS seeds, which seems to be an extremely centralized single point problem. But don’t forget, Bitcoin’s security model only requires you to connect to an honest peer node, which is enough to resist sybil attacks.
Therefore, a new node only needs to be able to connect to a DNS seed that is not under attack, and this seed will return the IP address of the honest node. However, in order to prevent all DNS nodes from being inaccessible for some reason, there is an alternative-a list of reliable node IP addresses that are hard-coded into the software, which will be updated with each new version release.
Under the security model built around these initialization parameters, full node operators do not need to trust X DNS seeds or Y Bitcoin Core software developers to provide them with real data. They only need to believe that 1/X DNS nodes have not suffered. Attack, or 1/Y Bitcoin Core software developers will honestly review the validity of hard-coded peer node changes.
There is no absolute security
From a deeper perspective, when you run a full node, you will trust the hardware and software you are running to a certain extent.
You can check the signature of your binary file with van der Laan’s in a variety of ways to verify that the software is reliable, but few people are willing to cause this trouble. As for how to verify the reliability of the hardware, this is a tricky question. If you need a secure hardware solution, the closest option is ORWL. If someone tries to tamper with ORWL, it will trigger its “self-destruct” mechanism.
However, since important hardware such as CPU and RAM are usually proprietary, you can never be 100% sure that they will not be compromised.
Bitcoin’s checks and balances
When you start to study the relationship between different participants in the Bitcoin system, you will find yourself in a fog.
The purpose of running a full node is to protect your financial sovereignty. This means that once you install and run a specific version of the software, it means that you have reached an agreement with the software and all other network participants-not only you will abide by the rules of the software, but also other network participants These rules must also be followed.
Therefore, if people want to make backward-compatible changes to the software’s rules, you must run the new version of the software to show that you explicitly agree to these rule changes. On the other hand, if it is a backward compatible rule change, even if you do not agree, it can be implemented on the network.
Someone highly summarized the internal checks and balances of Bitcoin:
The three power departments of Bitcoin governance:
- Full node (miners and developers can be vetoed)
- Miner (can veto the developer)
- Developer (can help others bypass certain vetoes)
It should be noted that the full-node software will not be updated automatically, this is by design. Automatic updates will cause the balance of power to tilt toward developers, allowing developers to force changes to the rules without the permission of nodes and miners.
Unfortunately, although the rule changes may be backward compatible on a technical level, years of experience have taught us that a sufficiently creative soft fork can also implement changes that violate the rules of the old version. For example, Vitalik Buterin once mentioned such an idea: to shorten the block time of Bitcoin from 10 minutes to 2 minutes through a soft fork, which will inevitably speed up the issuance of Bitcoin.
In the face of soft forks that they don’t like, full nodes have a trump card: use hard forks to draw a line with other miners who support soft forks. This (in terms of design) is difficult to implement, and it raises many questions about how to measure consensus and find nodes with a high economic weight.
Technically speaking, this kind of hard fork can be realized by changing the mining algorithm from double SHA256 to another hash function. Once successful, all SHA256 ASIC miners will not be able to be used to mine Bitcoin. Therefore, node operators should always be alert to changes in the Bitcoin ecosystem and remind miners that there is a risk of being replaced if they exceed their authority.
Many game theories will discuss the operation of miners and their threats to the security of Bitcoin. In my previous article, I speculated how the mining ecology might change. Although the degree of centralization of Bitcoin mining is not satisfactory, it still works well so far. This is because Bitcoin miners have invested a lot of money, and they will not risk huge losses to do evil in a system that is monitored by everyone.
Many Bitcoin users use lightweight clients instead of full nodes to access the network, because the former requires much less resources, but still provides strong security.
Clients that use Simple Payment Verification (SPV) will download a complete copy of the block headers of all blocks on the entire chain. This means that since the birth of Bitcoin, download and storage requirements will grow linearly over time. See section 8 of the Bitcoin white paper for details.
Satoshi Nakamoto wrote in the white paper that the SPV client “cannot verify the transaction by itself, but by associating the transaction with the blockchain, it can see that the nodes in the network have accepted the transaction. Blocking on the chain further confirms that the network has accepted the transaction”. SPV assumes that the transaction forgery after X block confirmations is extremely expensive.
SPV seems to have security comparable to a full node, but it introduces an additional assumption: as long as the block header and proof of work of a block are valid, all the transactions it contains are also valid. Because SPV clients will not verify all the consensus rules mentioned in Section 1 of this article, they assume that the node that responds to the transaction query request has already verified the consensus rules.
Another minor security difference is that peer nodes may hide information from you. If you run a full node, peer nodes can hide unconfirmed transactions and blocks from you. However, once you get a block from a peer node, no one can hide any transactions in this block from you. On the other hand, if you are running an SPV client, the peer node may provide you with the block header and then conceal the transaction information in the corresponding block.
SPV client can query related transactions of a certain address. Although peer nodes use fake transactions to deceive SPV clients at a high price (need to dig a block with sufficient PoW), they can lie about the Bloom filter used by SPV clients to query transactions ( bloom filter) No results. Another point to note is that due to the flaws of the Bloom filter, SPV has suffered a serious breach in privacy.
BitcoinJ explained the SPV security model well in an article. Regarding unconfirmed transactions, they pointed out:
In the SPV mode, as long as the node you are connected to forward a transaction to you, you can only believe that the transaction is valid. If the attacker can ensure that the nodes you are connected to are his, he can send you a completely invalid transaction (spending money that does not exist), and you will recognize that the transaction is valid.
For ordinary users, the security of SPV is “high enough”. Nevertheless, we can use SPV fraud proof to improve it. Although there has been some discussion about fraud proofs, the proposal on how to build them into the Bitcoin protocol has not yet been implemented.
Bitcoin network does not have 127.0.0.1
If you are not running a full node (and actually using it to verify transactions), then you must at least trust a third party to a certain degree, which will lead to differences in the security model. Please note that this does not require all users and businesses to directly build their software on Bitcoin Core’s RPC API.
Some alternative infrastructure configurations include but are not limited to:
1) Use the mobile wallet configuration such as the Android version of Bitcoin wallet, GreenAddress or Stash to query only your own full node wallet.
2) Build applications on SPV node libraries (such as BitcoinJ) and set these applications to connect only to your own full nodes. In BitcoinJ, this can be achieved by defining your own SeedPeer and passing it to your PeerGroup during initialization. With libbitcoin, you can use this example to define a network connection to a specific node.
3) Build a proxy server compatible with Bitcoin Core’s JSON-RPC API. This API will not only send some calls to third-party services, but also automatically verify the data returned by third-party services by calling the local full node. BitGo’s BitGoD software is an example. This hybrid model can achieve the best of both worlds: you can use advanced features provided by third parties while retaining your own financial sovereignty.
Full node: for freedom
Obviously, running your own full node is the safest solution and requires the fewest assumptions. It only costs a few hundred dollars to build a computer that can run a reliable full node. You might as well calculate this account and decide whether it is worth paying to protect your financial sovereignty.
Thanks to Kristov Atlas, Eric Martindale, Andrew Miller, and Kiara Roble for their review and feedback on this article.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/is-bitcoin-safe-in-depth-exploration-of-bitcoins-security-model-part-2/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.