foster/bitcoin-bitcoin-core
0
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-02-08 10:31:50 -05:00
Code Issues Activity
Bitcoin Core integration/staging tree
31213 commits 6 branches 321 tags 2.3 GiB
C++ 56.4%
C 22.7%
Python 17.6%
CMake 1%
Shell 0.8%
Other 1.3%
Find a file
MarcoFalke 22a9018649
Merge bitcoin/bitcoin#23306: Make AddrMan support multiple ports per IP 
92617b7a75 Make AddrMan support multiple ports per IP (Pieter Wuille)

Pull request description:

  For a long part of Bitcoin's history, this codebase has aggressively avoided making automatic connections to anything but nodes running on port 8333. I'd like to propose changing that, and this is a first PR necessary for that.

  The folklore justification (eventually actually added as a comment to the codebase in #20668) is that this is to prevent the Bitcoin P2P network from being leveraged to perform a DoS attack on other services, if their IP/port would get rumoured. It appears, at least the current network scale - and probably significantly larger - that the impact is very low at best (see calculations by vasild in https://github.com/bitcoin/bitcoin/issues/5150#issuecomment-853888909 e.g.). Another possible justification would be a risk that treating different IP:port combinations separately would help perform Eclipse attacks (by an attacker rumouring their own IP with many ports). This concern is (a) no different than what is possible with IPv6 (where large ranges of IP addresses are very cheaply available), and (b) already hopefully sufficiently addressed by addrman's design (which limits access through based selected based on network groups).

  And this policy has downsides too; in particular, a fixed port is easy to detect, and a very obvious sign a Bitcoin node is running there.

  One obstacle in moving away from a default port that is the fact that addrman is currently restricted to a single entry per IP address. If ports are no longer expected to be generally always the default one, we need to deal with the case where conflicting information is relayed. It turns out there is a very natural solution to this: treat (IP,port) combination exactly as we're treating IPs now; this automatically means that the same IP may appear with multiple ports, simply because those would be distinct entries. Given that indexing into addrman's bucket _already_ uses the port number, the only change required is making all addrman lookup be (IP,port) (aka `CService`) based, rather than IP (aka `CNetAddr`) based.

  This PR doesn't include any change to the actual outbound connection preference logic, as perhaps that's something that we want to phase in more gradually.

ACKs for top commit:
  jnewbery:
    Code review ACK 92617b7a75
  naumenkogs:
    ACK 92617b7a75
  ajtowns:
    ACK 92617b7a75
  vasild:
    ACK 92617b7a75

Tree-SHA512: 9eef06ce97a8b54a3f05fb8acf6941f253a9a5e0be8ce383dd05c44bb567cea243b74ee5667178e7497f6df2db93adab97ac66edbc37c883fd8ec840ee69a33f
2021-10-25 16:44:17 +02:00
.github doc: Remove label from good first issue template 2020-08-24 09:31:24 +02:00
.tx qt: Bump transifex slug for 22.x 2021-04-21 13:46:41 +02:00
build-aux/m4 Squashed 'src/univalue/' changes from 98fadc0909..a44caf65fe 2021-10-11 20:45:56 +08:00
build_msvc Merge bitcoin/bitcoin#22890: doc: Replace a link to Qt precompiled binaries with compile instructions 2021-10-07 08:39:52 +08:00
ci ci: Disable syscall sandbox in valgrind functional tests 2021-10-20 21:06:10 +02:00
contrib Merge bitcoin/bitcoin#22646: build: tighter Univalue integration, remove --with-system-univalue 2021-10-20 11:01:38 +08:00
depends Merge bitcoin/bitcoin#22783: build: Cleanup depends build system 2021-10-19 15:51:41 +08:00
doc doc: Add note on deleting past-EOL release branches 2021-10-20 18:45:03 +02:00
share Remove -rescan startup parameter 2021-09-30 12:06:27 +13:00
src Merge bitcoin/bitcoin#23306: Make AddrMan support multiple ports per IP 2021-10-25 16:44:17 +02:00
test Merge bitcoin/bitcoin#23312: tests: reduce feature_segwit.py usage of the legacy wallet 2021-10-25 15:32:27 +02:00
.cirrus.yml ci: Add vcpkg tools cache 2021-10-22 14:33:04 +03:00
.editorconfig ci: Drop AppVeyor CI integration 2021-09-07 06:12:53 +03:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore build: add *~ to .gitignore 2021-05-12 18:10:47 +02:00
.python-version Bump minimum python version to 3.6 2020-11-09 17:53:47 +10:00
.style.yapf test: .style.yapf: Set column_limit=160 2019-03-04 18:28:13 -05:00
autogen.sh scripted-diff: Bump copyright of files changed in 2019 2019-12-30 10:42:20 +13:00
configure.ac Merge bitcoin/bitcoin#23282: build: remove build stubs for external leveldb 2021-10-21 09:31:20 +08:00
CONTRIBUTING.md Enable TLS in links in documentation 2021-09-16 22:00:20 +00:00
COPYING doc: Update license year range to 2021 2020-12-30 16:24:47 +01:00
INSTALL.md doc: Added hyperlink for doc/build 2021-09-09 19:53:12 +05:30
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00
Makefile.am scripts: remove pixie.py 2021-10-12 08:36:21 +08:00
README.md doc: Rework internal and external links 2021-02-17 09:18:46 +01:00
REVIEWERS release: remove gitian 2021-08-31 09:37:23 +08:00
SECURITY.md doc: Remove explicit mention of version from SECURITY.md 2019-06-14 06:39:17 -04:00

README.md

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

Further information about Bitcoin Core is available in the doc folder.

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information read the original Bitcoin whitepaper.

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.