0022c84716
b061b35105seeds: Regenerate mainnet seeds (virtu)02dc45c506seeds: Pull nodes from Luke's seeder (virtu)7a2068a0ffseeds: Pull nodes from virtu's crawler (virtu) Pull request description: This builds on #30008 and adds data [exported](https://github.com/virtu/seed-exporter) by [my crawler](https://github.com/virtu/p2p-crawler) an additional source for seed nodes. Data covers all supported network types. [edit: Added Luke's seeder as input as well.] ### Motivation - Further decentralizes the seed node selection process (in the long term potentially enabling an _n_-source threshold for nodes to prevent a single source from entering malicious nodes) - No longer need to manually curate seed node list for any network type: See last paragraph of OP in #30008. My crawler has been [discovering the handful of available cjdns nodes](https://21.ninja/reachable-nodes/nodes-by-net-type/) for around two months, all but one of which meet the reliability criteria. - Alignment of uptime requirements for Onion and I2P nodes with those of clearnet nodes to 50%: If I'm reading the code correctly, seeders appear to optimize for up-to-dateness by using [lower connection timeouts](3c1a63c672/src/crawl.rs (L349)) than [Bitcoin Core](bc87ad9854/src/netbase.cpp (L40C27-L40C48)) to maximize throughput. Since my crawler does not have the same timeliness requirements, it opts for accuracy by using generous timeouts. As a result, its data contains additional eligible Onion (and other darknet nodes), as is shown in the histogram below. Around 4500 Onion nodes are discovered so far (blue); my data adds ~6400 more (orange); ~ 1500 nodes take longer than the default 20-second Bitcoin Core timeout and won't qualify as "good".  Here's the current results with 512 nodes for all networks except cjdns: <details> <summary>Using the extra data</summary> ``` IPv4 IPv6 Onion I2P CJDNS Pass 10335 2531 11545 1589 10 Initial 10335 2531 11545 1589 10 Skip entries with invalid address 5639 1431 11163 1589 8 After removing duplicates 5606 1417 11163 1589 8 Enforce minimal number of blocks 5606 1417 11163 1589 8 Require service bit 1 4873 1228 11163 1589 8 Require minimum uptime 4846 1225 11161 1588 8 Require a known and recent user agent 4846 1225 11161 1588 8 Filter out hosts with multiple bitcoin ports 512 512 512 512 8 Look up ASNs and limit results per ASN and per net ``` </details> <details> <summary>Before</summary> ``` IPv4 IPv6 Onion I2P CJDNS Pass 5772 1323 443 0 2 Initial 5772 1323 443 0 2 Skip entries with invalid address 4758 1110 443 0 2 After removing duplicates 4723 1094 443 0 2 Enforce minimal number of blocks 4723 1094 443 0 2 Require service bit 1 3732 867 443 0 2 Require minimum uptime 3718 864 443 0 2 Require a known and recent user agent 3718 864 443 0 2 Filter out hosts with multiple bitcoin ports 512 409 443 0 2 Look up ASNs and limit results per ASN and per net ``` </details> ### To dos - [x] Remove manual nodes and update README - [x] Mark nodes with connection times exceeding Bitcoin Core's default as bad in [exporter](https://github.com/virtu/seed-exporter): [done](https://github.com/virtu/seed-exporter/pull/12) - [x] Regenerate mainnet seeds - [x] Rebase, then remove WIP label once #30008 gets merged ACKs for top commit: achow101: ACKb061b35105fjahr: utACKb061b35105Tree-SHA512: 63e86220787251c7e8d2d5957bad69352e19ae17d7b9b2d27d8acddfec5bdafe588edb68d77d19c57f25f149de723e2eeadded0c8cf13eaca22dc33bd8cf92a0
Bitcoin Core integration/staging tree
For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.
What is Bitcoin Core?
Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and graphical user interface, which can be optionally built.
Further information about Bitcoin Core is available in the doc folder.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
Development Process
The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be
completely stable. Tags are created
regularly from release branches to indicate new official, stable release versions of Bitcoin Core.
The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.
The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.
Testing
Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.
Automated Testing
Developers are strongly encouraged to write unit tests for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: make check. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests, written
in Python.
These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py
The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.
Translations
Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.