Binding to multiple anonymous networks (esp. I2P)

grarpamp commented at 6:56 am on December 11, 2012: none

Suggesting that bitcoind be able to bind to multiple anonymous (and regular) networks at once. Inbound queries would reply out the same bind they were received on. Outbound initiates/broadcasts might be sent from all binds, or if impossible or out of context, to a specified one. Goal: Allow one daemon to service all networks [1] at once. [1] IPv4, IPv6, Tor, I2P, Phantom

Note it should always be made possible option to not bind to ‘*’ (all addresses), but only to ones supplied.

I’m not certain if -externalip can do this. -discover in doc/Tor.txt says: ‘If you want to run a dual stack, reachable from both Tor and IPv4 (or IPv6), you’ll need to either pass your other addresses using -externalip’ which implies maybe it can, but offers no syntax. Maybe it is a doc bug.

-externalip=foo.onion (or Tor’s OnionCat IPv6 /48) -externalip=bar.i2p (or I2P’s GarliCat IPv6 /48) -externalip=6addr (.phantom / interpreted from its IPv6 /48 prefix) -externalip=6addr -externalip=4addr

Also, since socks context via -proxy breaks down with more than one such anonymous net, there would also need to be: -tor=host:port (in Tor, in bitcoin) -i2p=host:port (in I2P, not in bitcoin) -phantom=host:port (not in Phantom, not in bitcoin) and maybe -proxyipv4=host:port -proxyipv6=host:port

gmaxwell commented at 6:59 am on December 11, 2012: contributor

What exactly is missing that you’re asking for here?

grarpamp commented at 7:06 am on December 11, 2012: none

editing in your query answer to ticket body.

gmaxwell commented at 7:14 am on December 11, 2012: contributor

There is already distinctive Tor and proxy settings for the socks outbound connections to IP vs Tor networks. externalip is used to set what you announce, and its used as documented.

Because of limited address space Bitcoin can not usefully directly address I2P today (so it can realistically only be inbound only for it, which just works) so there is nothing more to do at this time for I2P. I’m not aware of what phantom uses for addressing. Does anyone use it? Can its addresses be conflict free packed into public IPv6 addresses like we can with onion addresses?

grarpamp commented at 7:24 am on December 11, 2012: none

Phantom is in devel/test. It will work with any IPv6 enabled app. So when devs start advertising it it should just work. Phantom is also equivalent to Tor+OnionCat, both are 1:1 mappings using separate /48’s, they should just work. You can also use I2P+OnionCat, but I’m not sure best practice regarding the 128/256 conflict, consult zzz’s I2P forum.

gmaxwell commented at 7:31 am on December 11, 2012: contributor

I2P’s requires a resolution service, it’s not something which we can use to make native connections. (We don’t use onioncat itself with tor for all the important performance and privacy reasons, but we do use its addressing). In any case, I think we already do what you’re asking for here— except we only have the ability to IP4/6 and Tor/Onion addressed peers right now. We can happily multinet on those.

grarpamp commented at 7:51 am on December 11, 2012: none

Then full support of I2P could be a future bitcoin internal width enhancement since I2P is popular. You mean foo.i2p -> base32.b32.i2p? Yes, but you can still enter the full URI form… no resolution.

I think Phantom (and Tor/I2P+OnionCat) will be ok via additional -externalip=6addr arguments for inbound. But there will need to be something to tell bitcoin NOT to send those /48’s via any configured -proxy, thus letting the host routing table route them to those tunnel interfaces for outbound (because it’s extremely unlikely any such proxy will ever be rigged to do this discrimination and split forwarding). This can be done with an internal check for the default /48’s. But be sure to add some flags so the user can specify different /48’s in case they are running Tor/I2P/Phantom as testnets/alternets/privnets: -phantomv6=n/48, -torv6=n/48, -i2pv6=n/48

These are the default /48’s used by these nets: fd00:2522:3493::/48 - phantom fd60:db4d:ddb5::/48 - i2p + garlicat fd87:d87e:eb43::/48 - tor + onioncat

I would also doc how to multiple -externalip for now (for .onion, 6addr, 4addr).

Users may wish to use OnionCat for whatever purposes, so yes, apps (like bitcoin) should leave that decision to them.

laanwj commented at 9:52 am on May 9, 2014: member

There is a bitcoin fork that works on I2P, I am not sure what the status of it is, and he has never tried to get the changes upstream:

https://bitcointalk.org/index.php?topic=151181.0 https://github.com/VirtualDestructor/bitcoin-qt-i2p

laanwj renamed this:
~~Binding to multiple anonymous networks~~
Binding to multiple anonymous networks (esp. I2P)
on May 9, 2014

sipa commented at 10:49 am on May 9, 2014: member

So, “support” for an external relay network requires:

The ability to internally resolve the equivalent of the relay network’s “IP addresses”, and send them to a separately-configurable proxy service.
The ability to relay such “IP addresses” over the P2P network.

For Tor, we cheated, by reusing some address space within IPv6 (the onioncat range) as onion IP addresses. This allowed fixing both issues at once, as we already internally and on the P2P network use IPv6 everywhere.

I2P and cjdns cannot use this method, as their addresses are too large to fit in IPv6. Garlicat exists for mapping i2p into IPv6, but it requires an external lookup service to convert garlicat addresses to ful I2P addresses. I don’t know phantom.

If we want to support more types of networks, the first step is probably adding something like a CExtNetAddr, which represents either a CNetAddr or some address in another network. The connection/proxy logic could easily support that.

For relaying, such a CExtNetAddr would need to become part of the P2P protocol. Maybe we wish to push for that at some point, but probably together with other improvements like host keys and authenticated connections.

laanwj added the label P2P on May 9, 2014

laanwj added the label Feature on May 9, 2014

laanwj added the label Privacy on Aug 18, 2015

str4d commented at 11:07 pm on June 14, 2016: contributor

Note that in addition to being necessary for I2P support, this change will be necessary to migrate to Tor’s next-gen onion services (which will have addresses that are the same length as I2P’s B32s).

laanwj commented at 8:46 am on August 1, 2016: member

cjdns cannot use this method

Nit: Not true (anymore?) - cjdns uses a subset of IPv6 addresses, and bitcoind works fine over it.

laanwj removed the label Priority Low on Dec 6, 2017

laanwj commented at 8:45 pm on May 31, 2018: member

Note that in addition to being necessary for I2P support, this change will be necessary to migrate to Tor’s next-gen onion services (which will have addresses that are the same length as I2P’s B32s).

I’m planning to work on a BIP for this. Now that Tor v3 hidden services are becoming more common, I think it’s about time to extend the P2P protocol with a new kind of addr message that supports 256-bit network address (+ 8 bit network id + 16 bit port + ? bit service flags + 32 bit last seen time) instead of just the current 128 bit IPv6.

There was some discussion of this in the IRC meeting today: https://botbot.me/freenode/bitcoin-core-dev/2018-05-31/?msg=100660820&page=4

Some additional ideas that came up:

No longer embed Tor services in IPv6 onioncat (could keep doing this for HS v2, but just as well have separate network class for that)
How much to reserve for service bits (or whether it should be more than 64 as currently) wasn’t clear yet.
There were questions whether something should be added with regard to BIP151 (encryption), such as gossiping pubkeys - but probably not, as this is trivial to MiTM.
Using new addr to gossip the storage range of blocks for pruning - however, it is not clear how this would be more useful than NODE_NETWORK_LIMITED, given that ranges tend to change faster than nodes can gossip.

While looking around I found that there was some discussion in the zcash repository about this, but no concrete proposals yet: https://github.com/zcash/zcash/issues/1111 https://github.com/zcash/zcash/issues/3051 (and see also discussion in #9214)

laanwj commented at 3:15 pm on June 2, 2018: member

I’ve made a start with the addrv2 BIP spec here: https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1 Will start on a reference implementation next, and if that seems feasible post to the mailing list. @str4d it would be awesome if you could have a look some time if the I2P parts make sense.

fanquake deleted a comment on Mar 21, 2019

Fonta1n3 commented at 5:07 am on March 1, 2020: none

Note that in addition to being necessary for I2P support, this change will be necessary to migrate to Tor’s next-gen onion services (which will have addresses that are the same length as I2P’s B32s).

I’m planning to work on a BIP for this. Now that Tor v3 hidden services are becoming more common, I think it’s about time to extend the P2P protocol with a new kind of addr message that supports 256-bit network address (+ 8 bit network id + 16 bit port + ? bit service flags + 32 bit last seen time) instead of just the current 128 bit IPv6.

There was some discussion of this in the IRC meeting today: https://botbot.me/freenode/bitcoin-core-dev/2018-05-31/?msg=100660820&page=4

Some additional ideas that came up:

No longer embed Tor services in IPv6 onioncat (could keep doing this for HS v2, but just as well have separate network class for that)

How much to reserve for service bits (or whether it should be more than 64 as currently) wasn’t clear yet.

There were questions whether something should be added with regard to BIP151 (encryption), such as gossiping pubkeys - but probably not, as this is trivial to MiTM.

Using new addr to gossip the storage range of blocks for pruning - however, it is not clear how this would be more useful than NODE_NETWORK_LIMITED, given that ranges tend to change faster than nodes can gossip.

While looking around I found that there was some discussion in the zcash repository about this, but no concrete proposals yet: zcash/zcash#1111 zcash/zcash#3051 (and see also discussion in #9214)

Is it possible to also add tor V3 authentication so that attacking tor nodes over p2p becomes infeasible. Currently with V2 there seems to be a lot of attack vectors, adding the native V3 auth would go a long way to preventing any future attack vectors.

adamjonas commented at 1:01 am on December 23, 2020: member

Given that BIP155, #18884 (completed) and #20685 (in-progress) have all moved forward since this was last commented on, this can probably be closed.

adamjonas closed this on Jan 19, 2021

DrahtBot locked this on Aug 18, 2022

Binding to multiple anonymous networks (esp. I2P) #2091