{"id":12266,"date":"2026-08-23T19:38:15","date_gmt":"2026-08-23T19:38:15","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=12266"},"modified":"2026-08-23T19:38:15","modified_gmt":"2026-08-23T19:38:15","slug":"bitcoin-core-weighs-cjdns-removal-after-seven-good-nodes","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=12266","title":{"rendered":"Bitcoin Core weighs CJDNS removal after seven good nodes"},"content":{"rendered":"

<\/p>\n

\n

Bitcoin Core contributors are weighing whether a thinly used network transport offers valuable insurance or has become a liability too costly to retain.<\/p>\n

In the open CJDNS support discussion, Bitcoin Core member Andrew Chow said one seeder database held 25 CJDNS addresses, had reached 22 and classified only seven as good. The issue author, Martin Zumsande, reported seeing only three to four peers even though Bitcoin Core ships with 11 fixed CJDNS seeds.<\/p>\n

Those figures have prompted support for deprecation and a suggestion that Bitcoin Core warn users in a 32.x release before planning removal in 33.x. But that version sequence was posed as a question. As of Sunday, Aug. 23, the issue remained open in the 32.0 milestone, with its Development section empty of an implementation branch or pull request.<\/p>\n

Bitcoin Core implements CJDNS as optional peer-to-peer transport and address handling, outside Bitcoin’s consensus system. Issue #36041 instead asks whether Bitcoin Core should keep CJDNS address handling as a fallback when the thin peer pool may also make CJDNS-only nodes easier to surround.<\/p>\n

\n

Related Reading<\/span><\/p>\n

Bitcoin Core 22.0 just released. Here’s all you should know<\/h3>\n<\/p>\n

<\/span> <\/div>\n

Bitcoin Core\u2019s seven good nodes capture one seeder snapshot<\/h2>\n

The seeder numbers describe one crawler’s database at one point in time. The global CJDNS population may be larger because the figure covers only that crawler’s database.<\/p>\n

The seeder applies \u201cgood\u201d as a stricter technical filter than reachability. In Chow’s DNSSeedrs implementation, a node must pass checks covering its port, advertised network service, protocol version, chain height and rolling reliability. The reliability tests use several time windows and require minimum attempt counts. That explains how the seeder could reach 22 addresses while classifying only seven as good.<\/p>\n

Only seven of the 22 reached addresses cleared the good-node filters, leaving the usable pool shallow. Zumsande’s node found just three or four peers, and he offered low triple digits as a rough level that might justify continued support. The low-triple-digit benchmark was Zumsande’s alone, giving maintainers a number to argue over instead of only a general complaint about low usage.<\/p>\n

\"CJDNS\"CJDNS<\/p>\n

Peer-count arithmetic alone leaves the eclipse cost unknown. Bitcoin Core normally maintains eight full-relay outbound connections and two block-relay-only connections, with an occasional feeler or extra block-relay-only connection. A contributor suggested grounding any CJDNS threshold in the cost of filling those regular slots and eclipsing a CJDNS-only node.<\/p>\n

An eclipse attack isolates a node by monopolizing the peers that shape its view of the network. On a transport with a small known address set, an attacker has a more concentrated target. Bitcoin Core’s current CJDNS documentation already discourages CJDNS-only operation because a node may fail to fill its outbound slots, repeatedly try the few addresses it knows and become more susceptible to Sybil attacks.<\/p>\n