Add support for a cjdns network type #1498
Conversation
|
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. |
| @@ -647,6 +649,12 @@ bool CNetAddr::IsGarliCat() const | |||
| return (memcmp(ip, pchGarliCat, sizeof(pchGarliCat)) == 0); | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
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
|
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. |
|
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 |
|
This does not seem to have gathered any ACKs, and open questions remained unanswered, so recommend closing. |
|
There was some renewed discussion of the issue and I wanted to record the current state of the situation.
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:
|
ProcessNewBlock would return failure early if CheckBlock failed, before calling AcceptBlock. AcceptBlock also calls CheckBlock, and upon failure would update mapBlockIndex to indicate that a block was failed. By returning early in ProcessNewBlock, we were not marking blocks that fail a check in CheckBlock as permanently failed, and thus would continue to re-request and reprocess them.
… access violations. 066a558 [Wallet] Initialize zwalletMain to prevent memory access violations if it's not set. (furszy) Pull request description: Simple enough, last fix needed for CWallet usage in unit test. Initializing zwalletMain to null to prevent memory access violations if it's not being set. ACKs for top commit: random-zebra: utACK 066a558 Fuzzbawls: utACK 066a558 Tree-SHA512: d7e6f0559730a0eacc4c967abbf6285a766d048c488ef48ce10832e12a0f2e28e4ea62080e8a143331c2c8cbbc89f81ee7324624d5e9b32d527e3d265140189a
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:
The 'bind' and 'externalip' switches should be changed to your own cjdns address of course.