# Security ## A Tale of Two Attack Vectors Broadly speaking, there are two basic categories of attacks of interest to those in the blockchain space: network attacks and consensus attacks. Simplifying considerably, network attacks involve targeting a small number of nodes or users to steal their funds, stop transactions from being verified, promulgate fake data, or pursue other nefarious ends. Examples of network attacks include distributed denial of service (DDoS) attacks, eclipse attacks, and BGP hijacking. Consensus attacks are in many ways subtler and fundamentally involve the exploitation of a protocol’s consensus mechanism. The most famous example are the soi-disant “51%” attacks, in which a malicious actor gains control of 51% of the hashpower in a blockchain like Bitcoin, allowing them to double spend a cryptocurrency, stop transactions from being verified, and otherwise compromise the network’s integrity. ## Core’s Approach to Security Core mitigates network attacks through a combination of geographic dispersion of nodes and randomizing the selection of nodes for P2P communications. These are all validator-level precautions and are common to many blockchain projects. Where consensus attacks are concerned, the combination of DPoW, DPoS, and the validator election mechanism offers many desirable security properties. The fact that the validator mines blocks in a round-robin manner means that [selfish mining](#user-content-fn-1)[^1] is not possible, for example, because these exploits require manipulating the kind of pseudorandom mechanism that simply does not exist on Core. Censorship and transaction delays are potential threat vectors but are mitigated as long as there are honest validators in the set. For similar reasons, 51% attacks, Sybil attacks, and related exploits can’t be prevented outright, but attempting any of them is both economically unwise and very difficult to achieve, given the fact that validators are ranked by their hybrid score. An important part of thwarting long-range attacks is Core’s checkpointing scheme, wherein the network permanently freezes the blockchain’s history on a regular basis, adds a checkpoint hash to the codebase, and rejects any future transactions that aren’t consistent with these hashes. There are whole categories of insidious attacks that involve going back to a certain point in time and mining a competing chain that reverses transactions, prevents access to a network, etc. When used in conjunction with DPoW, checkpointing renders us invulnerable to this constellation of threats. For the mathematically inclined, Appendix A contains a proof stating that as long as less than $$\frac{1}{3}$$ of the nodes are malicious and enough blocks are confirmed, transactions on Satoshi Plus are provably safe. [^1]: “Selfish mining” refers to mining a block and not broadcasting it. If a miner continues to produce additional blocks, they could end up with a long chain that effectively acts like a fork of the main ledger. In Bitcoin, mining is competitive and selfish mining could prove profitable. With Core Chain, however, there is no way to do this because of the way that validators are elected and the way mining works. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://whitepaper.coredao.org/core-white-paper-v1.0.7/satoshi-plus-consensus/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.