| 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 |
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:
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
This is not an exhaustive list. This is mostly from looking at PRs or IRC meetings. Any mistakes are my own.
Q: In this video, John Newbery talks about verification vs computation, and he bring it up as a big reason why he thinks bitcoin can scale but is skeptical about ethereum. I think I get the general idea of what he’s saying but I might be missing something.
Is there a qualitative difference between verification and computation? And is it the fact that ethereum is capable of performing arbitrary computation that makes the whole thing difficult to scale, or is it that specifically smart contracts that require arbitrary computation won’t be able to scale (as in those contracts would be very expensive to run).
A: There is a big difference between verification and computation.
For instance:
bitcoin/bitcoin#16401 - package relay
bitcoin/bitcoin#16702 - asmap to improve bucketing
bitcoin/bitcoin#16974 - Walk pindexBestHeader back to ChainActive().Tip() if it is invalid
bitcoin/bitcoin#16856 - Do not allow descendants of BLOCK_FAILED_VALID blocks to be BLOCK_FAILED_VALID
bitcoin/bitcoin#16939 - p2p: Delay querying DNS seeds if addrman is populated
Error:
>>> [do_build] Command failed: git apply /Users/jonas/bitcoin-dir/bitcoin-maintainer-tools/patches/stripbuildinfo.patch
>>> [do_build] Could not apply patch to strip build info. Probably it needs to be updated
Checkout the patchset from the last patch:
git checkout 'master@{aug 1}'
src :
Let’s start by what you can do while typing. These keystrokes change only what happens on the input line (the line where you type stuff).
arrow left/right: move one character left or right.