Add support for a cjdns network type #1498

pull doublec wants to merge 1 commits into bitcoin:master from doublec:cjdns changing 2 files +18 −5

doublec commented at 11:08 PM on June 21, 2012: none
This pull request adds support for a CJDNS network type modeled after the existing support for tor and i2p networks.

Using "-onlynet=cjdns" and relevant -externalip, -bind and -addnode, allows running a bitcoind that communicates over cjdns only.

A cjdns/ip4 bridging node is running on fca5:372b:57be:78aa:e490:6b0f:da2a:c882 and can be used for testing. An example command for running a node that communicates over cjdns:
```
./bitcoind -onlynet=cjdns -addnode=fca5:372b:57be:78aa:e490:6b0f:da2a:c882 -bind=fc46:96cb:122a:4eff:fa50:24c4:2436:e564 -externalip=fc46:96cb:122a:4eff:fa50:24c4:2436:e564
```
The 'bind' and 'externalip' switches should be changed to your own cjdns address of course.
Add support for a cjdns network type 6602ae8f87
gavinandresen commented at 11:22 PM on June 21, 2012: contributor

Can you add a doc/CJDNS.txt with the information on how to configure?

I'll let people who know a lot more about networking than me to ACK or NACK.
in src/netbase.cpp:None in 6602ae8f87
```
 648 | @@ -647,6 +649,12 @@ bool CNetAddr::IsGarliCat() const
 649 |      return (memcmp(ip, pchGarliCat, sizeof(pchGarliCat)) == 0);
 650 |  }
 651 |  
```
cjdelisle commented at 11:26 PM on June 21, 2012:

It would be cool to see a comment explaining why fc00::/8 means cjdns. Here is the documentation on why cjdns will never use any addresses outside of the fc00::/8 range. https://github.com/cjdelisle/cjdns/blob/master/rfcs/Whitepaper.md#pulling-it-all-together

Here is the relevant RFC which explains why it is unlikely to see fc00::/8 addresses routed on the internet. http://tools.ietf.org/html/rfc4193
sipa commented at 8:51 PM on June 22, 2012: member

If I understand it correctly, CJDNS uses FC00::/8 as network range, which is half of RFC4193's unique local range?

I'm wonder whether this does risk clashing with anyone who wants to use RFC4193's range for other purposes. Inside the bitcoin P2P protocol this is not necessarily a problem (for now, it doesn't clash with anything, as the onioncat and garlicat ranges are inside the other half of the range), but we may want to be careful...

That said, CJDNS looks interesting, and I'd like to look into it.
BitcoinPullTester commented at 7:13 PM on August 9, 2012: none

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/6602ae8f878afa2036069fe278126162899e0c81 for binaries and test log.

This pull does not merge cleanly onto current master
jgarzik commented at 1:10 AM on September 5, 2012: contributor

This does not seem to have gathered any ACKs, and open questions remained unanswered, so recommend closing.
doublec closed this on Sep 5, 2012
cjdelisle commented at 6:24 AM on February 18, 2013: none
There was some renewed discussion of the issue and I wanted to record the current state of the situation.
1. All networks such as garlicat and onioncat are encoded by using reserved space in ipv6 addresses.
2. Bitcoin nodes relay addresses to everyone, ipv6 addresses are relayed to ipv4 nodes etc (changing this is non-trivial)
3. Cjdns uses an enormous amount of ipv6 space.
Bitcoin nodes will relay cjdns addresses to other nodes so if another network came along which uses the fc space, there would be a space collision. In theory cjdns is stealing a vast amount of space and is a relatively unpopular network. In practice if the space were used by multiple networks, the effect would be nodes attempting to connect to other nodes but being in the wrong network. Imagine some other network using the fc space, cjdns nodes would transfer the addresses to that network's nodes which would then try to connect to them, not knowing they are not from their own network.

In the long term, there will probably be a network ID attached to addresses which identifies them so not all networks need to be represented as IPv6 addresses.

My position:
1. It's ok in practice because for now no other such networks exist and if one were added then it would be a performance degradation issue, it would not be impossible.
2. If there's a network ID then the problem is solved. It still adds a certain amount of difficulty for the developers and in theory it's bad so it should not be merged unless a "good" number of people want to run bitcoin/cjdns nodes.
suprnurd referenced this in commit a12491448d on Dec 5, 2017
lateminer referenced this in commit ebfa5979a6 on May 6, 2020
DrahtBot locked this on Sep 8, 2021

Contributors

Labels