Add I2P support using I2P SAM #20685

vasild · 2020-12-17T12:49:55Z

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 · 2020-12-17T15:36:25Z

Awesome work, concept ACK.

DrahtBot · 2020-12-17T20:13:57Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

multiprocess: Add bitcoin-gui -ipcconnect option #19461 (multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky)
multiprocess: Add bitcoin-wallet -ipcconnect option #19460 (multiprocess: Add bitcoin-wallet -ipcconnect option by ryanofsky)
fuzz: Add fuzzing harness for TorController #19288 (fuzz: Add fuzzing harness for TorController by practicalswift)
multiprocess: Add basic spawn and IPC support #19160 (multiprocess: Add basic spawn and IPC support by ryanofsky)
Log RPC parameters (arguments) if -debug=rpcparams #16365 (Log RPC parameters (arguments) if -debug=rpcparams by LarryRuane)
Multiprocess bitcoin #10102 ([experimental] Multiprocess bitcoin by ryanofsky)

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 · 2020-12-18T09:05:29Z

Concept ACK

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

practicalswift · 2020-12-18T15:09:36Z

@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 · 2021-03-08T19:25:22Z

(did not test onlynet=i2p)

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

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 · 2021-05-03T13:48:31Z

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

jonatack · 2021-05-03T14:05:50Z

@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 · 2021-05-03T14:38:38Z

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).

sdaftuar · 2021-05-04T13:35:57Z

src/net.cpp

+        }
+
+        if (!advertising_listen_addr) {
+            AddLocal(conn.me, LOCAL_BIND);


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:

bitcoin/src/torcontrol.cpp

Line 354 in 0ca8b7e

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.

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);

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.

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

Yes.

Fixed in #21914.

…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

…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

Github-Pull: bitcoin#20685 Rebased-From: 0181e24

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

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

…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

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

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

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

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

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

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

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

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

…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

… 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

vasild mentioned this pull request Dec 17, 2020

Add I2P support using statically configured destinations #20254

Closed

DrahtBot added Build system Docs P2P RPC/REST/ZMQ Utils/log/libs labels Dec 17, 2020

vasild mentioned this pull request Dec 17, 2020

Allow setting I2P addresses #20662

Closed

This was referenced Dec 18, 2020

multiprocess: Add bitcoin-wallet -ipcconnect option #19460

Draft

multiprocess: Add basic spawn and IPC support #19160

Merged

Multiprocess bitcoin #10102

Draft

This was referenced Dec 19, 2020

net: Add NAT-PMP port forwarding support #18077

Merged

Cleanup of -debug=net log messages #20724

Merged

adamjonas mentioned this pull request Dec 23, 2020

Binding to multiple anonymous networks (esp. I2P) #2091

Closed

This was referenced Dec 23, 2020

doc: tor.md and -onlynet help updates #20757

Merged

[rpc] Remove deprecated fields from getpeerinfo #20755

Merged

jonatack mentioned this pull request Mar 8, 2021

Newsletters: add 139 (2021-03-10) bitcoinops/bitcoinops.github.io#526

Merged

6 tasks

laanwj mentioned this pull request Mar 23, 2021

connectivity to earth (public zerotier network) #8434

Closed

sdaftuar reviewed May 4, 2021

View reviewed changes

vasild mentioned this pull request May 11, 2021

net: use stronger AddLocal() for our I2P address #21914

Merged

This was referenced Jun 15, 2021

doc: add basic I2P documentation #22250

Merged

Add i2p BlockchainCommons/Learning-Bitcoin-from-the-Command-Line#221

Merged

satindergrewal mentioned this pull request Jun 23, 2021

Add I2P support using I2P SAM in bet chips-blockchain/bet#235

Open

luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Jun 27, 2021

net: recognize I2P from ParseNetwork() so that -onlynet=i2p works

dce01c8

Github-Pull: bitcoin#20685 Rebased-From: 0181e24

nullianity mentioned this pull request Jul 15, 2022

Rebooting overlay support: Merge v3 onions (critical), I2P SAM, and CJDNS from upstream Bitcoin. zcash/zcash#6075

Open

bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add I2P support using I2P SAM #20685

Add I2P support using I2P SAM #20685

vasild commented Dec 17, 2020 •

edited

laanwj commented Dec 17, 2020

DrahtBot commented Dec 17, 2020 •

edited

naumenkogs commented Dec 18, 2020

practicalswift commented Dec 18, 2020 •

edited

jonatack commented Mar 8, 2021

rebroad commented May 3, 2021

jonatack commented May 3, 2021

vasild commented May 3, 2021

sdaftuar May 4, 2021

vasild May 4, 2021

sdaftuar May 4, 2021 •

edited

vasild May 11, 2021

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

Add I2P support using I2P SAM #20685

Add I2P support using I2P SAM #20685

Conversation

vasild commented Dec 17, 2020 • edited

Overview of the changes

Make ReadBinary() and WriteBinary() reusable

Split CConnman::AcceptConnection()

Implement the I2P SAM protocol (not all of it)

Use I2P SAM to connect to and accept connections from I2P peers

laanwj commented Dec 17, 2020

DrahtBot commented Dec 17, 2020 • edited

Conflicts

naumenkogs commented Dec 18, 2020

practicalswift commented Dec 18, 2020 • edited

jonatack commented Mar 8, 2021

rebroad commented May 3, 2021

jonatack commented May 3, 2021

vasild commented May 3, 2021

sdaftuar May 4, 2021

Choose a reason for hiding this comment

vasild May 4, 2021

Choose a reason for hiding this comment

sdaftuar May 4, 2021 • edited

Choose a reason for hiding this comment

vasild May 11, 2021

Choose a reason for hiding this comment

vasild commented Dec 17, 2020 •

edited

Make `ReadBinary()` and `WriteBinary()` reusable

Split `CConnman::AcceptConnection()`

DrahtBot commented Dec 17, 2020 •

edited

practicalswift commented Dec 18, 2020 •

edited

sdaftuar May 4, 2021 •

edited