This is not an exhaustive list. This is mostly from looking at PRs or IRC meetings. Any mistakes are my own.
Eclipse attacks occur when a node is not connected to any honest peers on the network, and instead its peer connections are controlled by an adversary. Once denied connectivity to the honest network, a victim can be attacked in numerous ways, such as with double-spends or funds loss on layer 2 systems (such as the Lightning Network). Mining nodes attacked in this way can be forced to waste hashpower or be commandeered in selfish mining attacks, or generally aid in causing forks on the network.
This document attempts to describe the mechanisms implemented in Bitcoin Core to mitigate eclipse attacks followed by open questions and areas of further research.
A restart-based eclipse attack occurs when the adversary is able to sufficiently saturate the victim's address manager with attacker IPs (a.k.a. addrman flooding), and then the victim restarts. If the attack succeeds, the victim will lose its current outgoing connections due to the restart and be more lik
In April 2023, Bitcoin Core developers initiated the Priority Projects experiment to address a recognized bias in the development process towards smaller patches over more significant projects. The initiative aimed to help maintainers prioritize significant projects when facing competing demands for review attention.
The initial implementation used a straightforward approach:
| 1. feature_block.py | 108 s | |
| 2. p2p_segwit.py | 83 s | |
| 3. feature_taproot.py | 79 s | |
| 4. feature_maxuploadtarget.py | 72 s | |
| 5. mining_getblocktemplate_longpoll.py | 69 s | |
| 6. feature_fee_estimation.py | 60 s | |
| 7. feature_assumeutxo.py | 56 s | |
| 8. p2p_opportunistic_1p1c.py | 56 s | |
| 9. p2p_tx_download.py | 52 s | |
| 10. wallet_conflicts.py --descriptors | 52 s |