#32065 i2p: make a time gap between creating transient sessions and using them
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #32065 i2p: make a time gap between creating transient sessions and using them | Author silent 185d | 0 | Strong | 92 + 2 tests | |||
|
|
|
| ||||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | |||||||
Goal
Decouples I2P transient session creation from actual connection initiation. Bitcoin Core previously issued `SESSION CREATE` immediately before `STREAM CONNECT`, enabling external observers to correlate session establishment with outbound connection timing. The patch pre-creates a single transient session ahead of time so connections use an existing session with an arbitrary time delay.
Problem: When connecting to I2P peers using transient sessions, creating and immediately using a session in quick succession allows adversaries monitoring network traffic to correlate activity and link connection events. Users running outbound I2P connections without listening mode have their privacy weakened by this timing correlation.
Reviewability
Stale · Author silent 185d
No author activity for 185 days; a review may wait a long time for a response.
Waiting on (from the thread read):
- author: rebase and response to suggestion regarding session pre-creation conditions 2026-11-01
Agreement
Strong
substantive support, no open objection (zzzi2p)
Thread notes: Added jonatack's ACK modulo rebase and inline suggestion with diffs for pre-creating I2P sessions under more specific conditions.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| zzzi2p (none) | objection, approach | a pool of 10 idle sessions doubles network resource usage | fixed · fix pushed · reduced pre-created sessions to 1 | answered | yes | 2025-03-14: '10 standby sessions is a lot, except maybe at startup. If your I2P connections limit is 10, then you're doubling your network resource usage.' Status from: 2025-03-20: vasild: 'reduce the pre-created sessions to 1, given the above.' |
| zzzi2p (none) | objection, approach | starting many sessions at once at startup could trigger router tunnel build rate limits | answered · author explained sessions are not created in a tight loop and showed startup timings | answered | yes | 2025-03-14: 'The Java router has some tunnel build rate-limiting that may kick in.' Status from: 2025-03-18: vasild: 'This PR is not going to create a storm of I2P sessions creation at startup because new session creation is not being don' |
| eyedeekay (none) | objection, approach | holding a bank of 10 sessions is wasteful unless demand rate requires it | fixed · fix pushed · reduced pre-created sessions to 1 | answered | yes | 2025-03-15: 'keeping a bank of 10 of them is pretty wasteful' Status from: 2025-03-20: vasild: 'reduce the pre-created sessions to 1, given the above.' |
| mzumsande (member) | objection, approach | extra sessions expire after 10 minutes and waste resources if not used before expiration | fixed · fix pushed · reduced pre-created sessions to 1 | answered | yes | 2025-03-18: 'If we don't use these extra sessions before they expire, their creation would be a waste of ressources.' Status from: 2025-03-20: vasild: 'reduce the pre-created sessions to 1, given the above.' |
| mzumsande (member) | suggestion, approach | fill the unused sessions buffer with connections right after startup when using -onlynet=i2p | answered · author replied that serial connection opening makes pre-creating just one session preferable | answered | yes | 2025-03-18: 'Maybe it could make a sense to fill the m_unused_i2p_sessions buffer with 4 connections right after startup?' Status from: 2025-03-19: vasild: 'given that opening of new connections is done serially, one after another (not in parallel), and occasionally (except du' |
| jonatack (member) | question, scope | whether this change only applies when a node is configured with -i2pacceptincoming=0 | answered · author confirmed because accepting inbound connections uses a single persistent session | answered | yes | 2025-05-26: 'If I understand correctly, this change is only for if a node is configured with -i2pacceptincoming=0 to not accept inbound I2P connections?' Status from: 2025-05-30: vasild: 'Yes. That is because if it is accepting incoming connections (has a permanent listening I2P address) then there is just ' |
| jonatack (member) | suggestion, approach | consider pre-creating I2P sessions only when I2P is the preferred network or skipping pre-creation when the current attempt is I2P | open | answered | no | 2026-11-01: 'Would any of these options be a minor improvement? Feel free to ignore or defer for later.' |
Support:
- zzzi2p (none) (Concept ACK, 2025-03-14) [read]: supports decoupling session creation from use for anonymity
- jonatack (member) (ACK, 2026-11-01) [read: src/net.cpp]: modulo rebase [not substantive]
Participants:
- zzzi2p (none, objection, 2 statements 2025-03-14 to 2025-03-19): Concept ACKed, but objected to 10 standby sessions as excessive resource usage and raised concerns about startup rate limiting
- eyedeekay (none, objection, 1 statements 2025-03-15 to 2025-03-15): supported the concept but objected to keeping a bank of 10 standby sessions as wasteful
- mzumsande (member, objection, 1 statements 2025-03-18 to 2025-03-18): raised concern that extra sessions expiring after 10 minutes would waste network resources
- jonatack (member, support, 3 statements 2025-05-26 to 2026-11-01): ACK modulo rebase; suggested alternatives for when to pre-create sessions
- sedited (member, neutral, 2 statements 2026-09-17 to 2026-10-31): asked if author is still interested given months needing rebase and whether PR should be drafted
Files
3 lines under test/bench/ci.
- src/net.cpp +50/-23
- src/net.h +35/-23
- src/i2p.cpp +7/-0
- src/test/util/net.h +2/-1
Card
The short text the ranking pass compares across PRs.
PR #32065 introduces a time gap between creating transient I2P sessions and initiating connections over them to hinder network traffic correlation. For nodes running without a listening I2P address, creating sessions in advance decouples `SESSION CREATE` from `STREAM CONNECT`. I2P developers Concept ACKed the privacy improvement, and earlier concerns regarding idle tunnel resource usage were addressed by shrinking the pre-created session cache to one. The PR is currently stale and needs a rebase after several months of author inactivity.
Data
thread read through 2026-11-01 (21 statements), head 1808139f52
labels: P2P, Needs rebase
Categories
P2P
P3 · bug fix
Mitigates a timing correlation issue where issuing `SESSION CREATE` immediately before `STREAM CONNECT` allowed external observers to link outbound I2P connections. While an effective privacy improvement for users routing over I2P transient sessions, the timing leak is reasonably deferrable.
Membership: Changes I2P session management and connection handling in `src/net.cpp`, `src/net.h`, and `src/i2p.cpp` under the P2P area label.
Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 0