i2p: update leaseset encryption types #35696

jpk68 commented at 12:08 AM on July 10, 2026: none

Updates the I2P SAM leaseset parameters to 6,4 (MLKEM-768/ECIES-X25519), as is now recommended by the I2P project. ElGamal leasesets are now considered "legacy" and likely should not be used anymore.

i2p: update leaseset encryption types 412540e18d

DrahtBot commented at 12:08 AM on July 10, 2026: contributor

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35696.

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	kevkevinpal
Concept ACK	jonatack, zzzi2p
User requested bot ignore	janb84

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

sedited requested review from vasild on Jul 10, 2026

fanquake added the label Needs Backport (31.x) on Jul 10, 2026

kevkevinpal commented at 1:48 PM on July 12, 2026: contributor

ACK 412540e

I validated that this is the correct change. We could also just use 4 but I think it makes sense to use both 6,4

We might want to add a release note similar to how we did here https://github.com/bitcoin/bitcoin/pull/29440/changes#diff-e04cb1e9f29f76897c6b84334238f621ff45ba13cf180ad1d0d442d50ebe51f7R57-R60

Without the release note, breakages on old routes look like unexplained I2P breakages.

in src/i2p.cpp:428 in 412540e18d

 424 | @@ -425,7 +425,7 @@ void Session::CreateIfNotCreatedAlready()
 425 |          const Reply& reply = SendRequestAndGetReply(
 426 |              *sock,
 427 |              strprintf("SESSION CREATE STYLE=STREAM ID=%s DESTINATION=TRANSIENT SIGNATURE_TYPE=7 "
 428 | -                      "i2cp.leaseSetEncType=4,0 inbound.quantity=1 outbound.quantity=1",
 429 | +                      "i2cp.leaseSetEncType=6,4 inbound.quantity=1 outbound.quantity=1",

janb84 commented at 2:12 PM on July 13, 2026:

                      "i2cp.leaseSetEncType=6,4,0 inbound.quantity=1 outbound.quantity=1",

jonatack commented at 9:15 PM on July 22, 2026:

<strike>IIUC, this change should be fine in any case, as transient sessions are enabled only when -i2pacceptincoming is set to false, rather than the default of true. If an upgraded node running 6,4 initiates an outbound connection to a pre-#29200 peer, it fetches the legacy node's Type 0 LeaseSet. The upgraded node's local router, whether i2pd or the Java I2P one, still retains outbound ElGamal for backwards compatibility and the connection succeeds over Type 0 ElGamal.</strike>

Edit, correcting myself, I2P connection negotiation requires a mutually supported encryption type between both endpoints' local SAM sessions for the two tunnels. The comment #35696 (review) stands here as well.

in src/i2p.cpp:446 in 412540e18d

 442 | @@ -443,7 +443,7 @@ void Session::CreateIfNotCreatedAlready()
 443 |  
 444 |          SendRequestAndGetReply(*sock,
 445 |                                 strprintf("SESSION CREATE STYLE=STREAM ID=%s DESTINATION=%s "
 446 | -                                         "i2cp.leaseSetEncType=4,0 inbound.quantity=3 outbound.quantity=3",
 447 | +                                         "i2cp.leaseSetEncType=6,4 inbound.quantity=3 outbound.quantity=3",

janb84 commented at 2:12 PM on July 13, 2026:

                                         "i2cp.leaseSetEncType=6,4,0 inbound.quantity=3 outbound.quantity=3",

jonatack commented at 9:23 PM on July 22, 2026:

An argument could be made for setting 6,4,0 for the edge case of a pre-#29200 node attempting to make an I2P connection to a peer running this change, as the pre-#29200 node's SAM session only has a Type 0 ElGamal active and the connection with 6,4 will fail. I would guess there are a few dozen to maybe a couple of hundred such legacy I2P nodes.

If we do 6,4,0 instead, the 0 could be dropped when the i2pd and java i2p routers completely remove backward compatibility support for ElGamal (type 0), which they still drop down to today for pre-#29200 nodes.

janb84 commented at 2:15 PM on July 13, 2026: contributor

Why not create a setting for maximum compatibility ? or is ElGamal compromised ?

Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

jpk68 commented at 2:44 PM on July 13, 2026: none

Why not create a setting for maximum compatibility ? or is ElGamal compromised ?

Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

janb84 commented at 7:18 AM on July 14, 2026: contributor

~Approach NACK~, breaking backward compatibility on "likely should not be used anymore" isn't strong enough for me to justify it. ElGamal is not removed yet and there is no removal date picked (yet).

I think this PR is to early or should be restructured to explain why breaking backwards compatibility is justified. (or find a way to keep backwards compat.)

Edit: Given the usage stats, I'm not that concerned anymore about splitting the network.

eyedeekay commented at 6:56 PM on July 14, 2026: none

Hi, I'd just like to offer some informal clarification here. ElGamal in I2P is supported for now, and we don't know about any concrete vulnerabilities in the way we use it. However, there are good reasons to not use it:

It violates the "Don't roll your own crypto" rule. ElGamal in I2P comes from a time when things were more custom and less standardized on peer reviewed crypto.
It is not implemented by every router. New implementations of I2P have elected not to support ElGamal.
Java I2P and i2pd have elected to not support ElGamal alongside post-quantum support.

In essence, that means that as PQ gets rolled out in I2P, ElGamal will degrade in usability, and the valuable properties will be provided by the other crypto types. What this would look like is that you would be able to build ElGamal tunnels because the I2P and i2pd routers would still support it, but you would not be able to simultaneously use it to talk to ML-KEM enabled tunnels. If you're using old ElGamal crypto, consider migrating off of it by changing crypto types from 0, to 4,0, then to 4, then 6,4.

eyedeekay commented at 8:05 PM on July 14, 2026: none

Also, if there is a true need for backward-compatibility, then one option would be to create a separate, ElGamal-only tunnel for legacy support. That way, you could also toggle whether the legacy tunnel is enabled at all. I'm not convinced this would be truly necessary, but it would satisfy a backward compatibility requirement. If it is decided that backward compatibility with ElGamal is truly required, then I would recommend that be done in a separate PR.

nebula-21 commented at 4:35 PM on July 22, 2026: contributor

Why not create a setting for maximum compatibility ? or is ElGamal compromised ? Given the addition to 4 (ECIES-X25519) was only introduced in #29200 / v27 the PR in the current form will break compatibility with versions lower than v27.

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

Could you link where this was discussed or stated?

I found no documented limit for leaseSetEncType. The doc page states "Multiple encryption types are allowed". And i2pd docs show the example as i2cp.leaseSetEncType = <comma-separated codes> without specifying any limits.

If I'm not wrong, then @janb84's suggestion lgtm.

jonatack commented at 9:37 PM on July 22, 2026: member

Concept ACK 412540e18d877c4a34cf9c8fb43dfd34a603d5f5 modulo #35696 (review); it may be better to set 6,4,0 instead, and the 0 could be dropped later when the i2pd and java i2p routers completely remove backward compatibility support for ElGamal (type 0), which they still can drop down to today for pre-#29200 nodes.

If you're using old ElGamal crypto, consider migrating off of it by changing crypto types from 0, to 4,0, then to 4, then 6,4.

Alternatively, we could wait on this change until i2pd and java i2p drop ElGamal fully and then we upgrade at that time from 4,0 to 6,4.

DrahtBot requested review from janb84 on Jul 22, 2026

jonatack commented at 10:01 PM on July 22, 2026: member

According to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible.

I'm not sure. Are you talking about leaseSetType instead of leaseSetEncType?

i2pd seems to have a 6,4,0 setting in its config file: https://github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Config.cpp#L140

fanquake referenced this in commit 51143291a6 on Jul 23, 2026

jpk68 commented at 5:18 PM on July 23, 2026: none

Could you link where this was discussed or stated?

I found no documented limit for leaseSetEncType. The doc page states "Multiple encryption types are allowed". And i2pd docs show the example as i2cp.leaseSetEncType = <comma-separated codes> without specifying any limits.

If I'm not wrong, then @janb84's suggestion lgtm.

This was discussed in a DM with @eyedeekay. Upon looking further, it seems that i2pd does indeed support more than two encryption types at once, however, Java I2P does not. You can see this for yourself by attempting to create a session with such parameters through telnet:

SESSION STATUS RESULT=I2P_ERROR MESSAGE="Error creating I2PSocketManager: [SAM TCP Client(CLOSED)]: Failed to build tunnels - Disconnected from router while waiting for tunnels: bad session configuration parameters"

Alternatively, we could wait on this change until i2pd and java i2p drop ElGamal fully and > then we upgrade at that time from 4,0 to 6,4.

I think you'll be waiting quite some time for this to happen. In my opinion, it would be prudent to upgrade to PQ leasesets sooner rather than later, with the "compromise" of breaking compatibility with older routers using potentially insecure encryption types.

jonatack commented at 6:39 PM on July 23, 2026: member

In my opinion, it would be prudent to upgrade to PQ leasesets sooner rather than later, with the "compromise" of breaking compatibility

one option would be to create a separate, ElGamal-only tunnel for legacy support

I think not breaking connections with pre-#29200 peers is more important at this time and an option like that should be done first before upgrading to PQ.

Kino1994 referenced this in commit 26b4f19370 on Jul 26, 2026

zzzi2p commented at 6:49 PM on July 30, 2026: none

ACK to this PR as-is (6,4)

Confirming things stated above:

Java I2P and i2pd have supported type 6 since API 0.9.67 (Java I2P 2.10.0, i2pd 2.58.0, 2025-09)
Java I2P will fail SAM sessions with an unknown crypto type, and so 2.10.0 or higher will be required
i2pd will ignore unknown crypto types, so older versions should work.
i2pd does support 6,4,0.
Java I2P does not support 6,4,0 and will fail.
We have no plans to completely remove support for type 0 and you shouldn't wait for that to upgrade your network.

I recommend maintaining Java I2P compatibility, rather than maintaining compatibility with pre-2024 (29200/v27) type 0-only bitcoin peers. Those peers will still work, they will just eventually be "islanded", only able to talk to each other, after the rest of the bitcoin nodes upgrade. If your network upgrade rate is really that slow, it may take another few years before they are significantly impacted. It doesn't happen the day you release with this change. If, for example, 10% of your peers are more than 2 1/2 years old (pre 2024-04 v27) then it will be another estimated 2 1/2 years before the remaining ones are down to a 10% island of their own.

Instead of speculating about pre-v27 peer counts, you may take a look in the router to see, to help make your decision:

In the Java i2p console, you can verify the leaseset types on the client leasesets netdb tab if you have routerconsole.advanced=true in router.config. Look for peers with only ELGAMAL listed.

In the i2pd console, it reports the actual encryption type used, under LeaseSets for a particular destination. For example:

5xeoyfvtddmo5k3kxzv7b3d5risil6333ntqrr3yvx3yubz5tk3a ✘ 3 4

The last number 4 is the encryption type selected.

Alternative:

Make the encryption types configurable and include documentation on what to set for which type of router.

I do not recommend an additional ElGamal-only tunnel.

jonatack commented at 10:19 PM on July 30, 2026: member

@zzzi2p Thanks for the feedback and confirmations.

Those peers will still work, they will just eventually be "islanded", only able to talk to each other, after the rest of the bitcoin nodes upgrade.

Generally we want to avoid partitioning the network like that. Why urgent/important to upgrade now to PQ?

Java I2P does not support 6,4,0 and will fail. We have no plans to completely remove support for type 0 and you shouldn't wait for that to upgrade your network.

Any plans for I2P to support 6,4,0, like i2pd does?

zzzi2p commented at 11:08 PM on July 30, 2026: none

Hi Jon, glad you're participating in this discussion.

Generally we want to avoid partitioning the network like that. Why urgent/important to upgrade now to PQ?

This is not my PR and I wouldn't call it urgent or important. But it should happen at some point. The timing is up to you, as you weigh the coming PQ threats vs. compatibility issues. Different projects are making different decisons about PQ, and of course this is a sideshow compared to what you have coming on signatures.

The philosophy in our project, which I posit should apply to bitcoin-over-I2P users as well, is that for privacy- and security-focused users, the best way to maintain your anonymity and security is to stay on the latest release; if you don't upgrade, you will become part of a gradually-shrinking group of users that will in a couple years' time become a small "island" with reduced security properties.

While we try hard to maintain backward compatibility, the very reason people use I2P - anonymity and security - will gradually diminish if they don't stay current. It's inevitable, as we update to meet evolving threats.

So I'm suggesting that in the I2P context, the compatibility considerations for you might have a shorter horizon, maybe a couple years rather than forever.

Any plans for I2P to support 6,4,0, like i2pd does?

no, due to the complexity, and because any effort to further extend support for ElGamal is a waste of time.

jonatack commented at 11:16 PM on July 30, 2026: member

@zzzi2p For how long / until which release will Java I2P continue to work with the 4,0 setting?

Edit:

So I'm suggesting that in the I2P context, the compatibility considerations for you might have a shorter horizon, maybe a couple years rather than forever.

Seems like we have a couple years then before needing to upgrade (under normal circumstances).

zzzi2p commented at 12:27 AM on July 31, 2026: none

@zzzi2p For how long / until which release will Java I2P continue to work with the 4,0 setting?

We have no plan or schedule for that. However, i2pd is rumbling about removing type 0 support, and would presumably convert it transparently to type-4 only if they did.

Seems like we have a couple years then before needing to upgrade (under normal circumstances).

Well, type 4 dates back to 2020, to replace type 0 from 2003. So the clock started in 2020, and the pre-v27 users have been on an island almost since the beginning. From an anonymity-set perspective, your pre-v27 people are not getting what they think they're getting. See philosophy above. I'm trying to draw the distinction between "working" and "meeting privacy expectations".

It's a qualitative assessment, there is not a firm timeline.

My recommendation is you take this PR sometime in the next couple of releases, together with a release note strongly encouraging pre-v27 I2P users to update.

jonatack commented at 9:51 PM on August 11, 2026: member

Thank you @zzzi2p. Proposed a release note for upcoming v32.0 in #35951.

janb84 commented at 12:56 PM on August 12, 2026: contributor

To update this PR with some network information, moving to 6,4 (this PR) would only affect users in node versions less than 26.1 given that #29200 is even backported to 26.1 in #29209

According to https://coin.dance/nodes there are currently 26545 nodes, of those nodes there are roughly 2514 nodes (<26.1) So ~10% of the nodes are affected, I do not have any I2P usage-data but given the popularity of i2p that is only a small subset of those 2514 nodes.