{ "number": 35696, "repo": "bitcoin/bitcoin", "url": "https://github.com/bitcoin/bitcoin/pull/35696", "title": "i2p: update leaseset encryption types", "author": "jpk68", "author_association": "NONE", "created_at": "2026-07-10T00:08:17Z", "updated_at": "2026-08-12T13:04:51Z", "age_days": 69, "draft": false, "labels": [ "Needs Backport (31.x)" ], "milestone": null, "base": "master", "head_sha": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "head_ref": "i2p-leaseset", "head_repo": "jpk68/bitcoin", "head_history": [], "additions": 2, "deletions": 2, "changed_files": 1, "commit_count": 1, "size_bucket": "S", "mergeable_state": "blocked", "bot": { "drahtbot": { "present": true, "reviews": { "ack": [ { "login": "kevkevinpal", "url": "https://github.com/bitcoin/bitcoin/pull/35696#issuecomment-4951412021" } ], "concept_ack": [ { "login": "jonatack", "url": "https://github.com/bitcoin/bitcoin/pull/35696#pullrequestreview-4758833014" }, { "login": "zzzi2p", "url": "https://github.com/bitcoin/bitcoin/pull/35696#issuecomment-5134956635" } ] }, "conflicts": [] } }, "acks_parsed": { "kevkevinpal": { "kind": "ack", "hash": null, "t": "2026-07-12T13:48:46Z", "stale": false }, "jonatack": { "kind": "concept_ack", "hash": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "t": "2026-07-22T21:37:36Z", "stale": false }, "zzzi2p": { "kind": "ack", "hash": null, "t": "2026-07-30T18:49:08Z", "stale": false } }, "acks_tally": { "ack": 2, "stale_ack": 0, "concept_ack": 1, "approach_ack": 0, "nack": 0, "concept_nack": 0, "approach_nack": 0 }, "reviews": { "approved": 0, "changes_requested": 0, "distinct_reviewers": [ "eyedeekay", "janb84", "jonatack", "kevkevinpal", "nebula-21", "zzzi2p" ] }, "signals": { "needs_rebase": false, "ci_failed": false, "mergeable_state": "blocked", "last_author_activity": "2026-07-23T17:18:25Z", "last_reviewer_activity": "2026-08-12T12:56:49Z", "last_reviewer": "janb84", "author_silent_days": 55, "waiting_on_author_days": 36, "days_since_update": 36 }, "refs": { "mentioned": [ 29200, 29209 ], "depends_on": [], "fixes": [], "linked_issues": [], "references": [ { "number": 29200, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-01-09", "title": "net: create I2P sessions using both ECIES-X25519 and ElGamal encryption" }, { "number": 29209, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-02-16", "title": "[26.x] more backports" } ], "conflicts": [] }, "stack": { "shares_commits_with": [], "based_on": [], "base_for": [] }, "review_paths": [ "src/i2p.cpp" ], "body": "Updates the I2P SAM leaseset parameters to `6,4` (MLKEM-768/ECIES-X25519), as is [now recommended](https://i2p.net/en/docs/api/samv3/#signature-and-encryption-types) by the I2P project. ElGamal leasesets are now considered \"legacy\" and likely should not be used anymore.", "commits": [ { "sha": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "date": "2026-07-10T00:02:43Z", "message": "i2p: update leaseset encryption types" } ], "timeline": [ { "t": "2026-07-12T13:48:46Z", "kind": "comment", "who": "kevkevinpal", "assoc": "CONTRIBUTOR", "text": "ACK [412540e](https://github.com/bitcoin/bitcoin/pull/35696/commits/412540e18d877c4a34cf9c8fb43dfd34a603d5f5)\n\nI validated that this is the correct change. We could also just use `4` but I think it makes sense to use both `6,4`\n\nWe might want to add a release note similar to how we did here https://github.com/bitcoin/bitcoin/pull/29440/changes#diff-e04cb1e9f29f76897c6b84334238f621ff45ba13cf180ad1d0d442d50ebe51f7R57-R60\n\nWithout the release note, breakages on old routes look like unexplained I2P breakages." }, { "t": "2026-07-13T14:12:37Z", "kind": "review_comment", "who": "janb84", "assoc": "CONTRIBUTOR", "path": "src/i2p.cpp", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "in_reply_to": null, "text": "```suggestion\n \"i2cp.leaseSetEncType=6,4,0 inbound.quantity=1 outbound.quantity=1\",\n```" }, { "t": "2026-07-13T14:12:47Z", "kind": "review_comment", "who": "janb84", "assoc": "CONTRIBUTOR", "path": "src/i2p.cpp", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "in_reply_to": null, "text": "```suggestion\n \"i2cp.leaseSetEncType=6,4,0 inbound.quantity=3 outbound.quantity=3\",\n```" }, { "t": "2026-07-13T14:15:46Z", "kind": "review", "who": "janb84", "assoc": "CONTRIBUTOR", "state": "COMMENTED", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "text": "Why not create a setting for maximum compatibility ? or is ElGamal compromised ?\n\nGiven 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." }, { "t": "2026-07-13T14:44:45Z", "kind": "comment", "who": "jpk68", "assoc": "NONE", "text": "[quoted text omitted]\n\nAccording to the I2P devs, selecting three different leaseset types is not supported, so it seems this will not be possible." }, { "t": "2026-07-14T07:18:47Z", "kind": "comment", "who": "janb84", "assoc": "CONTRIBUTOR", "text": "~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).\n\nI 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.)\n\nEdit: Given the usage stats, I'm not that concerned anymore about splitting the network." }, { "t": "2026-07-14T18:56:53Z", "kind": "comment", "who": "eyedeekay", "assoc": "NONE", "text": "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:\n\n - 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.\n - It is not implemented by every router. New implementations of I2P have elected not to support ElGamal.\n - Java I2P and i2pd have elected to not support ElGamal alongside post-quantum support.\n\nIn 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`." }, { "t": "2026-07-14T20:05:22Z", "kind": "comment", "who": "eyedeekay", "assoc": "NONE", "text": "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." }, { "t": "2026-07-22T16:35:42Z", "kind": "comment", "who": "nebula-21", "assoc": "CONTRIBUTOR", "text": "[quoted text omitted]\n\nCould you link where this was discussed or stated?\n\nI found no documented limit for `leaseSetEncType`. The [doc page](https://i2p.net/en/docs/api/samv3/#signature-and-encryption-types) states \"Multiple encryption types are allowed\". And [i2pd docs](https://docs.i2pd.website/en/latest/user-guide/tunnels/#leaseset) show the example as `i2cp.leaseSetEncType = ` without specifying any limits.\n\nIf I'm not wrong, then @janb84's suggestion lgtm." }, { "t": "2026-07-22T21:15:19Z", "kind": "review_comment", "who": "jonatack", "assoc": "MEMBER", "path": "src/i2p.cpp", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "in_reply_to": null, "text": "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.\n\nEdit, correcting myself, I2P connection negotiation requires a mutually supported encryption type between both endpoints' local SAM sessions for the two tunnels. The comment https://github.com/bitcoin/bitcoin/pull/35696#discussion_r3633906935 stands here as well." }, { "t": "2026-07-22T21:23:06Z", "kind": "review_comment", "who": "jonatack", "assoc": "MEMBER", "path": "src/i2p.cpp", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "in_reply_to": null, "text": "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.\n\nIf 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." }, { "t": "2026-07-22T21:37:36Z", "kind": "review", "who": "jonatack", "assoc": "MEMBER", "state": "COMMENTED", "commit": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "text": "Concept ACK 412540e18d877c4a34cf9c8fb43dfd34a603d5f5 modulo https://github.com/bitcoin/bitcoin/pull/35696#discussion_r3633906935; 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.\n\n[quoted text omitted]\nAlternatively, 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." }, { "t": "2026-07-22T22:01:30Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nI'm not sure. Are you talking about `leaseSetType` instead of `leaseSetEncType`?\n\ni2pd seems to have a 6,4,0 setting in its config file: https://github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Config.cpp#L140" }, { "t": "2026-07-23T17:18:25Z", "kind": "comment", "who": "jpk68", "assoc": "NONE", "text": "[quoted text omitted]\n\nThis 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`:\n\n`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\"`\n\n[quoted text omitted]\nI 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." }, { "t": "2026-07-23T18:39:29Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "[quoted text omitted]\n\n[quoted text omitted]\nI 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." }, { "t": "2026-07-30T18:49:08Z", "kind": "comment", "who": "zzzi2p", "assoc": "NONE", "text": "ACK to this PR as-is (6,4)\n\nConfirming things stated above:\n\n- Java I2P and i2pd have supported type 6 since API 0.9.67 (Java I2P 2.10.0, i2pd 2.58.0, 2025-09)\n- Java I2P will fail SAM sessions with an unknown crypto type, and so 2.10.0 or higher will be required\n- i2pd will ignore unknown crypto types, so older versions should work.\n- i2pd does support 6,4,0.\n- Java I2P does not support 6,4,0 and will fail.\n- We have no plans to completely remove support for type 0 and you shouldn't wait for that to upgrade your network.\n\nI recommend maintaining Java I2P compatibility,\nrather than maintaining compatibility with pre-2024 (29200/v27) type 0-only bitcoin peers.\nThose peers will still work, they will just eventually be \"islanded\", only able\nto talk to each other, after the rest of the bitcoin nodes upgrade.\nIf your network upgrade rate is really that slow, it may take another few years before\nthey are significantly impacted. It doesn't happen the day you release with this change.\nIf, for example, 10% of your peers are more than 2 1/2 years old (pre 2024-04 v27)\nthen it will be another estimated 2 1/2 years before the remaining ones are down to a 10% island of their own.\n\nInstead of speculating about pre-v27 peer counts, you may take a look in the\nrouter to see, to help make your decision:\n\nIn the Java i2p console,\nyou can verify the leaseset types on the client leasesets netdb tab\nif you have routerconsole.advanced=true in router.config.\nLook for peers with only ELGAMAL listed.\n\nIn the i2pd console, it reports the actual encryption type used,\nunder LeaseSets for a particular destination.\nFor example:\n\n5xeoyfvtddmo5k3kxzv7b3d5risil6333ntqrr3yvx3yubz5tk3a \u2718 3 4\n\nThe last number 4 is the encryption type selected.\n\nAlternative:\n\nMake the encryption types configurable and include\ndocumentation on what to set for which type of router.\n\nI do not recommend an additional ElGamal-only tunnel." }, { "t": "2026-07-30T22:19:13Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "@zzzi2p Thanks for the feedback and confirmations.\n\n[quoted text omitted]\nto talk to each other, after the rest of the bitcoin nodes upgrade.\n\nGenerally we want to avoid partitioning the network like that. Why urgent/important to upgrade now to PQ?\n\n[quoted text omitted]\nAny plans for I2P to support 6,4,0, like i2pd does?" }, { "t": "2026-07-30T23:08:59Z", "kind": "comment", "who": "zzzi2p", "assoc": "NONE", "text": "Hi Jon, glad you're participating in this discussion.\n\n[quoted text omitted]\nThis 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.\n\nThe 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.\n\nWhile 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.\n\nSo 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.\n\n[quoted text omitted]\nno, due to the complexity, and because any effort to further extend support for ElGamal is a waste of time." }, { "t": "2026-07-30T23:16:56Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "@zzzi2p For how long / until which release will Java I2P continue to work with the 4,0 setting?\n\nEdit:\n\n[quoted text omitted]\nSeems like we have a couple years then before needing to upgrade (under normal circumstances)." }, { "t": "2026-07-31T00:27:23Z", "kind": "comment", "who": "zzzi2p", "assoc": "NONE", "text": "[quoted text omitted]\n\nWe 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.\n\n[quoted text omitted]\nWell, 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\".\n\nIt's a qualitative assessment, there is not a firm timeline.\n\nMy 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." }, { "t": "2026-08-11T21:51:26Z", "kind": "comment", "who": "jonatack", "assoc": "MEMBER", "text": "Thank you @zzzi2p. Proposed a release note for upcoming v32.0 in https://github.com/bitcoin/bitcoin/pull/35951." }, { "t": "2026-08-12T12:56:49Z", "kind": "comment", "who": "janb84", "assoc": "CONTRIBUTOR", "text": "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\n\nAccording 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." } ], "labels_log": [ { "t": "2026-07-10T15:35:15Z", "action": "labeled", "label": "Needs Backport (31.x)", "who": "fanquake" } ], "state_log": [], "text_chars": 12225, "text_tokens_estimate": 3056, "changed_paths": [ "src/i2p.cpp" ], "files": [ { "path": "src/i2p.cpp", "add": 2, "del": 2 } ], "test_lines": 0, "git": { "head": "412540e18d877c4a34cf9c8fb43dfd34a603d5f5", "head_matches_backup": true, "base": "81405fc7abbd1889f3978b8924e7acbe12b3403b", "commits": [ { "sha": "412540e18d", "subject": "i2p: update leaseset encryption types", "files": 1, "add": 2, "del": 2 } ], "patch_truncated": false }, "input_hash": "736cdd53ccde9c05", "extracted_at": "2026-09-17T16:15:31+00:00" }