Author: Jameson Lopp
Related Reading:
Original link:
https://blog.lopp.net/bitcoins-security-model-a-deep-dive/
Related Reading:first level title
Security Model Misunderstandings
Additionally, every blockchain system hardcodes the genesis block into the node software. You might think of the "shared history" (i.e., the ledger) as a kind of social contract - once a block is old enough, there is a consensus among all participants in the network that the block will never will be rolled back. When developers take an earlier mined block and use it to create a checkpoint, it is more of an accepted sanity check than an objective description of history.
In addition to checkpointing, how nodes implement self-booting is also an issue. Currently, the bootstrapping process for a Bitcoin node is to check that the node has locally stored data it has previously learned from peers. If not, the node will query a set of "DNS seeds" that are hardcoded 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 a DNS seed 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 a DNS seed. However, they have to convince the developer of a full node implementation to add their DNS seed host to the other party's software.
The bootstrapping process of new nodes relies on only 6 DNS seeds, which seems to be another extremely centralized single point of problem. But don't forget that Bitcoin's security model only requires you to be connected to an honest peer node, which is enough to resist Sybil attacks.
Therefore, a new node only needs to be able to connect to an uncompromised DNS seed, which returns the IP address of the honest node. However, in case all DNS nodes become unreachable for some reason, there is a fallback - a list of trusted node IP addresses that is hardcoded into the software and updated with each new release.
first level title
no absolute security
From a deeper level, when you run a full node, you trust the hardware and software you are running to a certain extent.
picture
first level title
Bitcoin's Decentralized Checks and Balances
When you start looking at the relationships between the different actors in the Bitcoin system, you can find yourself in a fog.
The purpose of running a full node is to protect your financial sovereignty. What this means is that once you install and run a particular version of software, you enter into an agreement with that software and with all other network participants — not only will you abide by the software’s rules, but other network participants These rules must also be followed.
So if people want to make backward-incompatible changes to the rules of the software, you have to run the new version of the software to express your explicit consent to those rule changes. On the other hand, if it's a backward compatible rule change, it can be enforced in the network even if you don't agree with it.
picture
The three main branches of Bitcoin governance:
Full nodes (can veto miners and developers)
miners (can veto developers)
Developers (can help others bypass certain vetoes)
It should be noted that the full node software will not be automatically updated, this is by design. Automatic updates would tip the balance of power in favor of developers, allowing developers to force rule changes without permission from nodes and miners.
It is a pity that although the rule changes may be backward compatible on a technical level, years of experience tell 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: the block time of Bitcoin will be shortened from 10 minutes to 2 minutes through a soft fork, which will inevitably speed up the issuance of Bitcoin.
In the face of unfavorable soft forks, full nodes have a trump card: use hard forks to draw a clear line with other miners who support soft forks. This is (by design) difficult to enforce and raises many questions about how to measure consensus and find nodes with high economic weight.
Technically, such a hard fork could be achieved by changing the mining algorithm from double SHA256 to another hash function. Once successful, all SHA256 ASIC miners will not be able to mine Bitcoin. Therefore, node operators should always be alert to changes in the Bitcoin ecosystem and remind miners of the risk of being replaced if they exceed their authority.
first level title
SPV Security
Many Bitcoin users access the network using lightweight clients rather than full nodes because they consume far fewer resources while still providing strong security.
picture
Satoshi Nakamoto wrote in the white paper that the SPV client "cannot verify the transaction itself, but by associating the transaction with the blockchain, it can see that the nodes in the network have accepted the transaction. As more and more districts If the block is on the chain, it further confirms that the network has accepted the transaction." SPV assumes that falsification of transactions after X block confirmations is extremely costly.
SPV seems to be as secure as a full node, but it introduces an additional assumption: as long as a block header and proof of work are valid, all transactions it contains are also valid. Because SPV clients do not verify all the consensus rules mentioned in Section 1 of this paper, they assume that nodes responding to transaction query requests have already verified the consensus rules.
Another minor security difference is the potential for peers to withhold information from you. If you run a full node, peers can hide unconfirmed transactions and blocks from you. But once you get a block from your peers, no one can hide any transactions in that block from you. On the other hand, if you're running an SPV client, it's possible for peers to provide you with block headers and then withhold the transactions in the corresponding blocks.
SPV clients can query related transactions of an address. Although it is expensive for peers to fool SPV clients with fake transactions (needing to mine a block with sufficient PoW), they can lie about the Bloom filter that SPV clients use to query transactions ( bloom filter) has no result. Another point to note is that SPV suffers from severe privacy breaches due to flaws in Bloom filters.
BitcoinJ has an excellent article on SPV's security model. Regarding unconfirmed transactions, they state:
In SPV mode, as long as the node you are connected to forwards a transaction to you, you can only believe that the transaction is valid. If an attacker can ensure that the nodes you are connected to are all his, they can send you a completely invalid transaction (spending money that does not exist), and you will accept that this transaction is valid.
first level title
Bitcoin network does not have 127.0.0.1
If you're not running a full node (and actually using it to validate transactions), you're at least somewhat trusting a third party, which makes a difference in the security model. Note that this does not require all users and businesses to build their software directly on top of Bitcoin Core's RPC API.
Some alternative infrastructure configurations include, but are not limited to:
picture
2) Build applications on SPV node libraries (such as BitcoinJ) and set these applications to only connect 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 network connections to specific nodes.
first level title
Full Node: For Freedom
Obviously, running your own full node is the safest option and requires the fewest assumptions. It only costs a few hundred dollars to build a computer capable of running a reliable full node. You might as well do the math and decide if it's 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.
