Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add I2P support using I2P SAM #20685

Merged
merged 20 commits into from
Mar 2, 2021
Merged

Add I2P support using I2P SAM #20685

merged 20 commits into from
Mar 2, 2021

Conversation

vasild
Copy link
Contributor

@vasild vasild commented Dec 17, 2020

Add I2P support by using the I2P SAM 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 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()

@laanwj
Copy link
Member

laanwj commented Dec 17, 2020

Awesome work, concept ACK.

@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 17, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@naumenkogs
Copy link
Member

Concept ACK


Once this is enabled, we should clearly communicate that using a non-popular overlay has privacy/security side-effects

@practicalswift
Copy link
Contributor

practicalswift commented Dec 18, 2020

@vasild Nice work!

I like the abstraction (Sock) you've added on top of the socket API. I'm adding something similar in #19203 (see MockableSocket and FuzzedSocket) to allow for fuzzing the more low-level parts of our networking code (in this specific case a regression fuzz harness for CVE-2017-18350).

If you have time: please check that PR out. It would be great if your socket abstraction also covered the needs of the the "fuzzed socket" use case. Ideally I'd like to implement my low-level networking code fuzzers using your socket abstraction (something along the lines of class FuzzedSock : public Sock) :)

Aside from of the I2P work I think your socket abstraction would be valuable on a stand-alone PR basis :)

@jonatack
Copy link
Member

jonatack commented Mar 8, 2021

(did not test onlynet=i2p)

Since writing that, I've been running onlynet=i2p with onlynet=onion and it seems to be working well.

maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Mar 19, 2021
52dd40a test: add missing netaddress include headers (Jon Atack)
6f09c0f util: add missing braces and apply clang format to SplitHostPort() (Jon Atack)
2875a76 util: add ParseUInt16(), use it in SplitHostPort() (Jon Atack)
6423c81 p2p, refactor: pass and use uint16_t CService::port as uint16_t (Jon Atack)

Pull request description:

  As noticed during review today in bitcoin/bitcoin#20685 (comment) of the upcoming I2P network support, `CService::port` is `uint16_t` but is passed around the codebase and into the ctors as `int`, which causes uneeded conversions and casts. We can avoid these (including in the incoming I2P code without further changes to it) by using ports with the correct type. The remaining conversions are pushed out to the user input boundaries where they can be range-checked and raise with user feedback in the next patch.

ACKs for top commit:
  practicalswift:
    cr ACK 52dd40a: patch looks correct
  MarcoFalke:
    cr ACK 52dd40a
  vasild:
    ACK 52dd40a

Tree-SHA512: 203c1cab3189a206c55ecada77b9548b810281cdc533252b8e3330ae0606b467731c75f730ce9deb07cbaab66facf97e1ffd2051084ff9077cba6750366b0432
@rebroad
Copy link
Contributor

rebroad commented May 3, 2021

@jonatack those i2p pings look much higher than the tor pings. Is that normal? Does i2p offer any advantage over tor?

@jonatack
Copy link
Member

jonatack commented May 3, 2021

@rebroad indeed (see #21261). An advantage is potentially better decentralization, network robustness and censorship resistance, e.g. I2P may be operational when Tor isn't or has degraded operation, like in January and February.

@vasild
Copy link
Contributor Author

vasild commented May 3, 2021

In addition, I2P connections have a "source address" - it is certain that the peer who connects from a given I2P address to us possesses the private key that corresponds to that I2P address. This can be used for white-listing "friends". It is a stronger guarantee than IP addresses (which can be spoofed by e.g. your ISP).

}

if (!advertising_listen_addr) {
AddLocal(conn.me, LOCAL_BIND);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't entirely understand how these enums (LOCAL_BIND, LOCAL_MANUAL, etc) are meant to be used, but I wonder if this should be LOCAL_MANUAL instead? That seems to be what we use for listening on an onion address:

AddLocal(service, LOCAL_MANUAL);

I noticed that when I'm running with -externalip, I don't get my i2p address listed as a local address (presumably because fDiscover gets defaulted to false and then anything less than LOCAL_MANUAL is ignored in AddLocal()), even though my onion address is unaffected by the setting. Changing this to LOCAL_MANUAL seems to fix this issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played with the LOCAL_* enums, but I don't remember why I chose LOCAL_BIND :-( I wonder why AddLocal() induced by -externalip did not work:

bitcoin/src/init.cpp

Lines 1304 to 1307 in 0ca8b7e

for (const std::string& strAddr : args.GetArgs("-externalip")) {
CService addrLocal;
if (Lookup(strAddr, addrLocal, GetListenPort(), fNameLookup) && addrLocal.IsValid())
AddLocal(addrLocal, LOCAL_MANUAL);

Copy link
Member

@sdaftuar sdaftuar May 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I should have been more clear -- I was using -externalip with an ipv4 address (this node is listening on an ipv4 address, onion address, and i2p address). However I noticed that with -externalip enabled, the AddLocal for the i2p address didn't work.

Presumably if I set -discover=1 explicitly then it would have worked? But I was just surprised that there's a difference between what we do for onion vs i2p.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably if I set -discover=1 explicitly then it would have worked?

Yes.

Fixed in #21914.

laanwj added a commit to bitcoin-core/gui that referenced this pull request Jun 14, 2021
…for multiple networks, add I2P peers

1b1088d test: add combined I2P/onion/localhost eviction protection tests (Jon Atack)
7c2284e test: add tests for inbound eviction protection of I2P peers (Jon Atack)
ce02dd1 p2p: extend inbound eviction protection by network to I2P peers (Jon Atack)
70bbc62 test: add combined onion/localhost eviction protection coverage (Jon Atack)
045cb40 p2p: remove unused m_is_onion member from NodeEvictionCandidate struct (Jon Atack)
310fab4 p2p: remove unused CompareLocalHostTimeConnected() (Jon Atack)
9e889e8 p2p: remove unused CompareOnionTimeConnected() (Jon Atack)
787d46b p2p: update ProtectEvictionCandidatesByRatio() doxygen docs (Jon Atack)
1e15acf p2p: make ProtectEvictionCandidatesByRatio() fully ratio-based (Jon Atack)
3f8105c test: remove combined onion/localhost eviction protection tests (Jon Atack)
38a81a8 p2p: add CompareNodeNetworkTime() comparator struct (Jon Atack)
4ee7aec p2p: add m_network to NodeEvictionCandidate struct (Jon Atack)
7321e6f p2p, refactor: rename vEvictionCandidates to eviction_candidates (Jon Atack)
ec590f1 p2p, refactor: improve constness in ProtectEvictionCandidatesByRatio() (Jon Atack)
4a19f50 test: add ALL_NETWORKS to test utilities (Jon Atack)
519e76b test: speed up and simplify peer_eviction_test (Jon Atack)
1cde800 p2p, refactor: rm redundant erase_size calculation in SelectNodeToEvict() (Jon Atack)

Pull request description:

  Continuing the work in #20197 and #20685, this pull updates and abstracts our inbound eviction protection to make it fully ratio-based and easily extensible to peers connected via high-latency privacy networks that we newly support, like I2P and perhaps others soon, as these peers are disadvantaged by the latency criteria of our eviction logic.

  It then adds eviction protection for peers connected over I2P.  As described in bitcoin/bitcoin#20685 (comment), we've observed over the past few months that I2P peers have a min ping latency similar to or greater than that of onion peers.

  The algorithm is a basically a multi-pass knapsack:

  - Count the number of eviction candidates in each of the disadvantaged
    privacy networks.

  - Sort the networks from lower to higher candidate counts, so that
    a network with fewer candidates will have the first opportunity
    for any unused slots remaining from the previous iteration.  In
    the case of a tie in candidate counts, priority is given by array
    member order from first to last, guesstimated to favor more unusual
    networks.

  - Iterate through the networks in this order.  On each iteration,
    allocate each network an equal number of protected slots targeting
    a total number of candidates to protect, provided any slots remain
    in the knapsack.

  - Protect the candidates in that network having the longest uptime,
    if any in that network are present.

  - Continue iterating as long as we have non-allocated slots
    remaining and candidates available to protect.

  The goal of this logic is to favorise the diversity of our peer connections.

  The individual commit messages describe each change in more detail.

  Special thank you to Vasil Dimov for the excellent review feedback and the algorithm improvement that made this change much better than it would have been otherwise. Thanks also to Antoine Riard, whose review feedback nudged this change to protect disadvantaged networks having fewer, rather than more, eviction candidates.

ACKs for top commit:
  laanwj:
    Code review re-ACK 1b1088d
  vasild:
    ACK 1b1088d

Tree-SHA512: 722f790ff11f2969c79e45a5e0e938d94df78df8687e77002f32e3ef5c72a9ac10ebf8c7a9eb7f71882c97ab0e67b2778191effdb747d9ca54d7c23c2ed19a90
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 14, 2021
…iple networks, add I2P peers

1b1088d test: add combined I2P/onion/localhost eviction protection tests (Jon Atack)
7c2284e test: add tests for inbound eviction protection of I2P peers (Jon Atack)
ce02dd1 p2p: extend inbound eviction protection by network to I2P peers (Jon Atack)
70bbc62 test: add combined onion/localhost eviction protection coverage (Jon Atack)
045cb40 p2p: remove unused m_is_onion member from NodeEvictionCandidate struct (Jon Atack)
310fab4 p2p: remove unused CompareLocalHostTimeConnected() (Jon Atack)
9e889e8 p2p: remove unused CompareOnionTimeConnected() (Jon Atack)
787d46b p2p: update ProtectEvictionCandidatesByRatio() doxygen docs (Jon Atack)
1e15acf p2p: make ProtectEvictionCandidatesByRatio() fully ratio-based (Jon Atack)
3f8105c test: remove combined onion/localhost eviction protection tests (Jon Atack)
38a81a8 p2p: add CompareNodeNetworkTime() comparator struct (Jon Atack)
4ee7aec p2p: add m_network to NodeEvictionCandidate struct (Jon Atack)
7321e6f p2p, refactor: rename vEvictionCandidates to eviction_candidates (Jon Atack)
ec590f1 p2p, refactor: improve constness in ProtectEvictionCandidatesByRatio() (Jon Atack)
4a19f50 test: add ALL_NETWORKS to test utilities (Jon Atack)
519e76b test: speed up and simplify peer_eviction_test (Jon Atack)
1cde800 p2p, refactor: rm redundant erase_size calculation in SelectNodeToEvict() (Jon Atack)

Pull request description:

  Continuing the work in bitcoin#20197 and bitcoin#20685, this pull updates and abstracts our inbound eviction protection to make it fully ratio-based and easily extensible to peers connected via high-latency privacy networks that we newly support, like I2P and perhaps others soon, as these peers are disadvantaged by the latency criteria of our eviction logic.

  It then adds eviction protection for peers connected over I2P.  As described in bitcoin#20685 (comment), we've observed over the past few months that I2P peers have a min ping latency similar to or greater than that of onion peers.

  The algorithm is a basically a multi-pass knapsack:

  - Count the number of eviction candidates in each of the disadvantaged
    privacy networks.

  - Sort the networks from lower to higher candidate counts, so that
    a network with fewer candidates will have the first opportunity
    for any unused slots remaining from the previous iteration.  In
    the case of a tie in candidate counts, priority is given by array
    member order from first to last, guesstimated to favor more unusual
    networks.

  - Iterate through the networks in this order.  On each iteration,
    allocate each network an equal number of protected slots targeting
    a total number of candidates to protect, provided any slots remain
    in the knapsack.

  - Protect the candidates in that network having the longest uptime,
    if any in that network are present.

  - Continue iterating as long as we have non-allocated slots
    remaining and candidates available to protect.

  The goal of this logic is to favorise the diversity of our peer connections.

  The individual commit messages describe each change in more detail.

  Special thank you to Vasil Dimov for the excellent review feedback and the algorithm improvement that made this change much better than it would have been otherwise. Thanks also to Antoine Riard, whose review feedback nudged this change to protect disadvantaged networks having fewer, rather than more, eviction candidates.

ACKs for top commit:
  laanwj:
    Code review re-ACK 1b1088d
  vasild:
    ACK 1b1088d

Tree-SHA512: 722f790ff11f2969c79e45a5e0e938d94df78df8687e77002f32e3ef5c72a9ac10ebf8c7a9eb7f71882c97ab0e67b2778191effdb747d9ca54d7c23c2ed19a90
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Jun 27, 2021
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
Extract `ReadBinaryFile()` and `WriteBinaryFile()` from `torcontrol.cpp` to its own `readwritefile.{h,cpp}` files, so that it can be reused from other modules.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [1/20]
bitcoin/bitcoin@4cba2fd

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11012
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
> util: fix ReadBinaryFile() returning partial contents
>
> If an error occurs and `fread()` returns `0` (nothing was read) then the
> code before this patch would have returned "success" with a partially
> read contents of the file.
bitcoin/bitcoin@8b6e4b3

> util: fix WriteBinaryFile() claiming success even if error occurred
>
> `fclose()` is flushing any buffered data to disk, so if it fails then
> that could mean that the data was not completely written to disk.
>
> Thus, check if `fclose()` succeeds and only then claim success from
> `WriteBinaryFile()`.
bitcoin/bitcoin@545bc5f

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [2&3/20]

Depends on D11012

Test Plan:
`ninja all check-all`

eviewers:

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11013
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
…r in CConnman::AcceptConnection()

Summary:
> net: check for invalid socket earlier in CConnman::AcceptConnection()
>
> This check is related to an `accept()` failure. So do the check earlier,
> closer to the `accept()` call.
>
> This will allow to isolate the `accept()`-specific code at the beginning
> of `CConnman::AcceptConnection()` and reuse the code that follows it.

bitcoin/bitcoin@2560589

> net: get the bind address earlier in CConnman::AcceptConnection()
>
> Call `GetBindAddress()` earlier in `CConnman::AcceptConnection()`. That
> is specific to the TCP protocol and makes the code below it reusable for
> other protocols, if the caller provides `addr_bind`, retrieved by other
> means.

bitcoin/bitcoin@1f75a65

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [4&5/20]

Depends on D11013

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11014
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
Isolate the second half of `CConnman::AcceptConnection()` into a new
separate method, which could be reused if we accept incoming connections
by other means than `accept()` (first half of
`CConnman::AcceptConnection()`).

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [6/20]
bitcoin/bitcoin@7c224fd

Depends on D11014

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11015
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
Our local (bind) address is already saved in `CNode::addrBind` and there
is no need to re-retrieve it again with `GetBindAddress()`.

Also, for I2P connections `CNode::addrBind` would contain our I2P
address, but `GetBindAddress()` would return something like
`127.0.0.1:RANDOM_PORT`.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [7/20]
bitcoin/bitcoin@f6c267d

Depends on D11015

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11016
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
Recognize also I2P addresses in the form `base32hashofpublickey.b32.i2p`
from `CNetAddr::SetSpecial()`.

This makes `Lookup()` support them, which in turn makes it possible to
manually connect to an I2P node by using
`-proxy=i2p_socks5_proxy:port -addnode=i2p_address.b32.i2p:port`

Co-authored-by: Lucas Ontivero <lucasontivero@gmail.com>

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [8/20]
bitcoin/bitcoin@cff65c4
Depends on D11016

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11017
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 10, 2022
Summary:
Move `maxWait` out of `InterruptibleRecv()` and rename it to
`MAX_WAIT_FOR_IO` so that it can be reused by other code.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [9/20]
bitcoin/bitcoin@34bcfab

Depends on D11017

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11018
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 11, 2022
Summary:
Deduplicate `MSG_NOSIGNAL` and `MSG_DONTWAIT` definitions from `net.cpp`
and `netbase.cpp` to `compat.h` where they can also be reused by other
code.

This is a backport of [[bitcoin/bitcoin#20685 | [[bitcoin/bitcoin#20685 | core#20685]]]] [10/20]
bitcoin/bitcoin@78fdfbe

Depends on D11018

Test Plan:
`ninja all check-all`

eviewers:

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11019
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 11, 2022
Summary:
Previously `Sock::Wait()` would not have signaled to the caller whether a timeout or one of the requested events occurred since that was not needed by any of the callers.

Such functionality will be needed in the I2P implementation, thus extend the `Sock::Wait()` method.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [11/20]
bitcoin/bitcoin@ea18453

Depends on D11019

Test Plan: `ninja all check-all`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11022
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 11, 2022
Summary:
This will be convenient in the I2P SAM implementation.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [13/20]
bitcoin/bitcoin@5bac7e4

Depends on D11023

Test Plan:
With clang-tidy,
`ninja`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11024
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 15, 2022
Summary:
Introduce two new options to reach the I2P network:

* `-i2psam=<ip:port>` point to the I2P SAM proxy. If this is set then
  the I2P network is considered reachable and we can make outgoing
  connections to I2P peers via that proxy. We listen for and accept
  incoming connections from I2P peers if the below is set in addition to
  `-i2psam=<ip:port>`

* `-i2pacceptincoming` if this is set together with `-i2psam=<ip:port>`
  then we accept incoming I2P connections via the I2P SAM proxy.

Add functional tests.

This is a backport of [[bitcoin/bitcoin#20685 | core#20685]] [15/20]
bitcoin/bitcoin@76c35c6

Depends on D11025 and D11028

Test Plan:
`ninja all check-all`

Install `i2prouter`, start it (`i2prouter start`) , start the SAM bridge (can be done in a browser http://127.0.0.1:7657/configclients), then run:
```
ninja && src/bitcoind -regtest -i2psam=127.0.0.1:7656 -debug=i2p
```

At this point, it still does not do much, but the new command line options are accepted.

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11027
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 15, 2022
…ng connections from CConnman

Summary:
> net: add I2P to the reachability map
>
> Update `CNetAddr::GetReachabilityFrom()` to recognize the I2P network so
> that we would prefer to advertise our I2P address to I2P peers.

bitcoin/bitcoin@9559bd1

> net: make outgoing I2P connections from CConnman

bitcoin/bitcoin@0635233

> net: accept incoming I2P connections from CConnman

https://github.com/bitcoin/bitcoin/pull/20685/commits/b905363fa8b0bb03fe34b53b5410880f42e0af39i

> net: use stronger AddLocal() for our I2P address
bitcoin/bitcoin@105941b

This is a backport of  [[bitcoin/bitcoin#20685 | core#20685]] [16,17,18/20] and [[bitcoin/bitcoin#21914 | core#21914]]

Depends on D11027

Test Plan:
`ninja all check-all`

Run `bitcoind` using I2P (see detailed test plan in D11027).
`ninja && src/bitcoind -regtest -i2psam=127.0.0.1:7656 -debug=i2p`

Now you can see new interesting log messages:

```
2022-02-11T14:35:42Z i2paccept thread start
2022-02-11T14:35:42Z I2P: Creating SAM session with 127.0.0.1:7656
2022-02-11T14:35:45Z I2P: SAM session created: session id=xxxxxxxxxx, my address=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.b32.i2p:18444
2022-02-11T14:35:45Z AddLocal(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.b32.i2p:18444,2)
```

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11029
Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Feb 15, 2022
… not skip I2P in GetNetworkNames()

Summary:
> net: recognize I2P from ParseNetwork() so that -onlynet=i2p works
bitcoin/bitcoin@0181e24

> net: Do not skip the I2P network from GetNetworkNames()
>
> So that help texts include "i2p" in:
> * `./bitcoind -help` (in `-onlynet` description)
> * `getpeerinfo` RPC
> * `getnetworkinfo` RPC
>
> Co-authored-by: Jon Atack <jon@atack.com>
bitcoin/bitcoin@a701fcf

This concludes backport of [[bitcoin/bitcoin#20685 | core#20685]] [19,20/20]
Depends on D11029 and D11036

Test Plan:
`ninja all check-all`

`src/bitcoind -regtest -i2psam=127.0.0.1:7656 -onlynet=i2p -debug=i2p`

Reviewers: #bitcoin_abc, Fabien

Reviewed By: #bitcoin_abc, Fabien

Subscribers: Fabien

Differential Revision: https://reviews.bitcoinabc.org/D11037
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.