b9f41df1ea
a701fcf01fnet: Do not skip the I2P network from GetNetworkNames() (Vasil Dimov)0181e24439net: recognize I2P from ParseNetwork() so that -onlynet=i2p works (Vasil Dimov)b905363fa8net: accept incoming I2P connections from CConnman (Vasil Dimov)0635233a1enet: make outgoing I2P connections from CConnman (Vasil Dimov)9559bd1404net: add I2P to the reachability map (Vasil Dimov)76c35c60f3init: introduce I2P connectivity options (Vasil Dimov)c22daa2ecfnet: implement the necessary parts of the I2P SAM protocol (Vasil Dimov)5bac7e45e1net: extend Sock with a method to check whether connected (Vasil Dimov)42c779f503net: extend Sock with methods for robust send & read until terminator (Vasil Dimov)ea1845315anet: extend Sock::Wait() to report a timeout (Vasil Dimov)78fdfbea66net: dedup MSG_NOSIGNAL and MSG_DONTWAIT definitions (Vasil Dimov)34bcfab562net: move the constant maxWait out of InterruptibleRecv() (Vasil Dimov)cff65c4a27net: extend CNetAddr::SetSpecial() to support I2P (Vasil Dimov)f6c267db3bnet: avoid unnecessary GetBindAddress() call (Vasil Dimov)7c224fdac4net: isolate the protocol-agnostic part of CConnman::AcceptConnection() (Vasil Dimov)1f75a653ddnet: get the bind address earlier in CConnman::AcceptConnection() (Vasil Dimov)25605895afnet: check for invalid socket earlier in CConnman::AcceptConnection() (Vasil Dimov)545bc5f81dutil: fix WriteBinaryFile() claiming success even if error occurred (Vasil Dimov)8b6e4b3b23util: fix ReadBinaryFile() returning partial contents (Vasil Dimov)4cba2fdafautil: extract {Read,Write}BinaryFile() to its own files (Vasil Dimov) Pull request description: Add I2P support by using the [I2P SAM](https://geti2p.net/en/docs/api/samv3) protocol. Unlike Tor, for incoming connections we get the I2P address of the peer (and they also receive ours when we are the connection initiator). Two new options are added: ``` -i2psam=<ip:port> I2P SAM proxy to reach I2P peers and accept I2P connections (default: none) -i2pacceptincoming If set and -i2psam is also set then incoming I2P connections are accepted via the SAM proxy. If this is not set but -i2psam is set then only outgoing connections will be made to the I2P network. Ignored if -i2psam is not set. Notice that listening for incoming I2P connections is done through the SAM proxy, not by binding to a local address and port (default: true) ``` # Overview of the changes ## Make `ReadBinary()` and `WriteBinary()` reusable We would need to dump the I2P private key to a file and read it back later. Move those two functions out of `torcontrol.cpp`. ``` util: extract {Read,Write}BinaryFile() to its own files util: fix ReadBinaryFile() returning partial contents util: fix WriteBinaryFile() claiming success even if error occurred ``` ## Split `CConnman::AcceptConnection()` Most of `CConnman::AcceptConnection()` is agnostic of how the socket was accepted. The other part of it deals with the details of the `accept(2)` system call. Split those so that the protocol-agnostic part can be reused if we accept a socket by other means. ``` net: check for invalid socket earlier in CConnman::AcceptConnection() net: get the bind address earlier in CConnman::AcceptConnection() net: isolate the protocol-agnostic part of CConnman::AcceptConnection() net: avoid unnecessary GetBindAddress() call ``` ## Implement the I2P [SAM](https://geti2p.net/en/docs/api/samv3) protocol (not all of it) Just the parts that would enable us to make outgoing and accept incoming I2P connections. ``` net: extend CNetAddr::SetSpecial() to support I2P net: move the constant maxWait out of InterruptibleRecv() net: dedup MSG_NOSIGNAL and MSG_DONTWAIT definitions net: extend Sock::Wait() to report a timeout net: extend Sock with methods for robust send & read until terminator net: extend Sock with a method to check whether connected net: implement the necessary parts of the I2P SAM protocol ``` ## Use I2P SAM to connect to and accept connections from I2P peers Profit from all of the preceding commits. ``` init: introduce I2P connectivity options net: add I2P to the reachability map net: make outgoing I2P connections from CConnman net: accept incoming I2P connections from CConnman net: recognize I2P from ParseNetwork() so that -onlynet=i2p works net: Do not skip the I2P network from GetNetworkNames() ``` ACKs for top commit: laanwj: re-ACKa701fcf01fjonatack: re-ACKa701fcf01freviewed diff per `git range-diffad898122a7bb34 a701fcf`, debug built and launched bitcoind with i2pd v2.35 running a dual I2P+Torv3 service with the I2P config settings listed below (did not test `onlynet=i2p`); operation appears nominal (same as it has been these past weeks), and tested the bitcoind help outputs grepping for `-i i2p` and the rpc getpeerinfo and getnetworkinfo helps Tree-SHA512: de42090c9c0bf23b43b5839f5b4fc4b3a2657bde1e45c796b5f3c7bf83cb8ec6ca4278f8a89e45108ece92f9b573cafea3b42a06bc09076b40a196c909b6610e
Bitcoin Core integration/staging tree
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.