2.3.0-12 Important Dev Build
Pre-release
I2P 2.3.0-12 Needs Testers!
I2P is closing in on the long-delayed release of the 2.4.0 router, which
contains a major redesign of one of the oldest and most essential shared
systems in I2P, the Network Database, or NetDB. The NetDB is I2P's DHT, a
variant of Kademlia which uses a technique called "Floodfill" to elect peers
to flood out information efficiently. If the DHT doesn't work, the routers that
make up the network won't be able to find the peers that it needs to operate, so
we have to be very sure that we've done it correctly.
TL:DR This change needs widespread testing
If you want to help, you can get a dev build at our official Github:
After downloading, copy the i2pupdate.su3 file to your I2P install directory and
restart. In about a minute, your I2P router will be upgraded to the new version.
Want to learn more? Read on...
This change will allow I2P to manage multiple versions of the NetDB, which may
co-exist in different "Contexts" on the same router, allowing them to enforce
secure behavior based upon their role when used by the router. In the new
design, a NetDB can assigned either a "main" role, or a "client" role.
In this new model, every router has a single "main" NetDB, which is used for
Floodfill operations, network maintenance, and detatched LeaseSet lookups.
However, routers that have Client Tunnels also have an equal number of client
NetDBs, which hold only the information required to operate their clients. When
a client publishes it's LeaseSet out a client tunnel, it is managed from within
the client NetDB, and when a client needs a LeaseSet, it is looked up and stored
in the client NetDB. This allows 2 things to change:
- when using the main NetDB, the router is able to handle every LeaseSet in
exactly the same way, including those belonging to it's own clients. - it allows us to maintain and organize multiple copies of a single LeaseSet
so that a client maintains a copy of all the LeaseSets it needs, and the client
is solely responsible for keeping them up to date.
This allows us to greatly simplify the way we handle LeaseSets by identifying
how the LeaseSet will be used with the context in which it is being stored. This
design can eliminate an entire hypothetical attack class where an attacker
attempts to confuse the DHT about the origins of a particular LeaseSet. As an
added benefit of employing this technique, the kinds of information that a NetDB
needs to use is known in advance. This is therefore a significant advance for
I2P's security and efficiency.
As I said in the pre-release forum post, this change has the potential to break
the network, and it cannot go live if we're not sure it's working correctly.
Please help us test the new NetDB, and report your issues at: