Integrating Kovri? #943

New Issue

2017-02-08T09:20:55+01:00

CameronRuggles commented

2017-02-08 09:20:55 +01:00

(Migrated from github.com)

It seems like it could be valuable to integrate Kovri, which is a C++ version of I2P being built by the Monero developers.

This could help hide from where the messages are originating and limit the ability of correlation attacks.

https://github.com/monero-project/kovri

It seems like it could be valuable to integrate Kovri, which is a C++ version of I2P being built by the Monero developers. This could help hide from where the messages are originating and limit the ability of correlation attacks. https://github.com/monero-project/kovri

PeterSurda commented

2017-03-17 19:47:02 +01:00

(Migrated from github.com)

I'm not opposed to it, but it requires a protocol change (because the I2P addresses don't fit into the current addr variables) so it would have to wait until more protocol changes are gathered.

jakobvarmose commented

2017-03-18 15:45:32 +01:00

(Migrated from github.com)

Why not use a new protocol message named "i2paddr" that will include the I2P addresses. Then the old nodes would just ignore it.

PeterSurda commented

2017-03-18 16:12:45 +01:00

(Migrated from github.com)

@jakobvarmose What an interesting proposition. I need to think about it but I'm inclined to agree with you. I'm redesigning the network system anyway, so it will be easier for developers to add new commands.

PeterSurda commented

2017-03-19 15:03:53 +01:00

(Migrated from github.com)

The "version" command won't be compatible with a different addressing scheme. However it probably isn't a big deal as the values from this command aren't really usable if using an anonymising layer.

The current net_addr specification also only allows 32bit streams and would have to be expanded to 64 to coincide with the rest of the protocol anyway. So I propose to merge these two attempts by creating a new command and a new data type that is both able to handle 64bit stream identifiers and a greater range of address types. Let's call it "addrv2" or "addr64". The data type would add a new field, addr_type, a varint representing an enum, bump the stream length from 32bit to 64bit and that of the "IPv6/4" field from 64 to 256bit (the length of an I2P identifier). Also it could change the "stream" field to an array, so that multi-stream node could be advertised more efficiently and make routing path discovery easier.

The "version" command won't be compatible with a different addressing scheme. However it probably isn't a big deal as the values from this command aren't really usable if using an anonymising layer. The current net_addr specification also only allows 32bit streams and would have to be expanded to 64 to coincide with the rest of the protocol anyway. So I propose to merge these two attempts by creating a new command and a new data type that is both able to handle 64bit stream identifiers and a greater range of address types. Let's call it "addrv2" or "addr64". The data type would add a new field, addr_type, a varint representing an enum, bump the stream length from 32bit to 64bit and that of the "IPv6/4" field from 64 to 256bit (the length of an I2P identifier). Also it could change the "stream" field to an array, so that multi-stream node could be advertised more efficiently and make routing path discovery easier.

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-03-03#943