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

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17783 (util: Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior by ryanofsky)
• #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
• #17493 (util: Forbid ambiguous multiple assignments in config file 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.

Thanks for this. You're on the right track here and we also appreciate the updates on your blog.

Not sure of the audience (users vs. downstreams) for this doc vs. your blog,
or whether this doc is more about your current release or your next one.
So I won't offer a detailed review.

Elaborating my request from OP of the ticket, overall, the messaging that would be most helpful is:

• Emphasize that I2P is a P2P network (just like Bitcoin!), encourage high share limits (or discourage limit setting at all) to protect anonymity and contribute to the network
• Be sure to run latest version of Java I2P (2.1.0 or later) or i2pd (2.45.0 or later)
• For now, discourage -i2pacceptincoming=0, especially on low-performance hardware or low-bandwidth, until we work through the issues.
• I don't know if anybody is trying to bootstrap the whole blockchain over i2p, or if that's even possible, but that's a really bad idea also

Thanks again.

whether this doc is more about your current release or your next one

Its the only i2p doc in this repository that users and developers can refer, update etc. for minimal and important things required to use i2p with bitcoin core. Not release specific. It was added in #22250 (2021) and updated multiple times since then.

There is also a doc for Tor: /doc/tor.md

* Emphasize that I2P is a P2P network (just like Bitcoin!), encourage high share limits (or discourage limit setting at all) to protect anonymity and contribute to the network

Done.

* Be sure to run latest version of Java I2P (2.1.0 or later) or i2pd (2.45.0 or later)

Dropped the versions in the documentation as they go stale. Presumably users will install current versions.

* For now, discourage -i2pacceptincoming=0, especially on low-performance hardware or low-bandwidth, until we work through the issues.

Done.

* I don't know if anybody is trying to bootstrap the whole blockchain over i2p, or if that's even possible, but that's a really bad idea also

Indeed, this was discouraged in the documentation, as it takes a long time.

Thanks for the feedback, everyone. Pushed an update and brought this out of draft.

don't know if anybody is trying to bootstrap the whole blockchain over i2p, or if that's even possible, but that's a really bad idea also

Maybe this shouldn't be allowed by code ?

Maybe this shouldn't be allowed by code ?

I thought about this but would prefer not to limit it unless it's been shown that this is really causing a serious issue with the network, both in principle to not make an exception for one network, and also doing it several releases after adding I2P support, as any users that do would see their nodes not working anymore after upgrading to that release of Bitcoin Core.

ACK

ACK 3e1d294

Iin the last 24h of running my node I see the following stats via nethogs, for Bitcoin Core v24.0 with ~11 I2P peers, ~85 HTTP peers and ~13 onion peers:

For contrast Tor has used ~600 MB of data total (figure shared with core-lightning). This is roughly the same usage pattern I saw which led me to try and limit I2P traffic only to bitcoin peers initially -- in fact a few months ago when monitoring for longer periods, I found I2P using more than double the bitcoind totals.

I accept (and agree!) that we should want to and encourage contributing back to the wider I2P network for it's network health and, for me personally it's no issue, as I'm on an unmetered connection. But I still wonder whether a comment around "expected" I2P bandwidth usage might be warranted in a future PR to give a heads up to entities with limited resources?

@willcl-ark Interesting feedback (thanks!), worth measuring how much bandwidth is used after #26837 and upgrading to the latest releases, currently Java I2P 2.1.0 and i2pd 2.45.1.