DragonX/dragonx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

net: repair DragonX peer discovery, broken three separate ways

Browse Source 
A DRAGONX node had no working peer discovery. Both mechanisms were broken, and a
third bug hid the fact.

1. DNS seeds were Hush's, and all three are dead. chainparams_commandline() sets an
   assetchain's port, magic, blocktime, upgrade heights and checkpoints but never
   touches vSeeds or vFixedSeeds, so DRAGONX silently inherited CMainParams':
   seed1.hush.is, seed2.hush.is and dns.leto.net. None of the three has an A record
   any more -- verified against 1.1.1.1 and 8.8.8.8, with google.com and
   node1..node5.dragonx.is resolving fine from the same host as a control. Replaced
   with the five DragonX node hostnames, which do resolve and do listen.

2. Every fixed seed carried port 0. contrib/seeds/generate-seeds.py documents its
   input as <ip>:<port>, but contrib/seeds/nodes_main.txt held bare IPs, so
   parse_spec() took the port as empty and emitted 0x00,0x00 for all five entries.
   The fixed-seed fallback -- which exists precisely for when DNS seeding yields
   nothing -- was therefore handing out unconnectable addresses. Added the port to
   nodes_main.txt and regenerated; entries now end 0x55,0x08 (21768).

3. ThreadDNSAddressSeed never incremented `found`, so "%d addresses found from DNS
   seeds" printed 0 unconditionally, whether seeding worked or not. That is almost
   certainly why nobody noticed the seeds had gone dead: the one diagnostic that
   would have shown it was hardcoded to say zero.

Verified on a fresh datadir (empty addrman, separate ports, real node untouched):
DNS seeding now reports "5 addresses found from DNS seeds" where it previously
reported 0, and the fixed-seed path adds 5 entries carrying the correct port.

Note on scope: the five hostnames are single-A-record hosts, so each contributes one
address rather than the spread a real seeder returns. A dedicated DNS seeder, or
simply a round-robin A record over the seed set, would be the proper fix and needs
only a DNS change rather than a release. This restores a working discovery path;
it does not make it a good one.

Also corrected the generated header's #endif comment, which said
HUSH_CHAINPARAMSSEEDS_H while the guard is DRAGONX_CHAINPARAMSSEEDS_H.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
DanS
2026-08-26 00:11:55 +02:00
co-authored by Claude Opus 5
parent 4dc57e80b1
commit 499f02a905
5 changed files with 35 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/chainparamsseeds.h
+6 -6
View File
@@ -11,14 +11,14 @@
// Each line contains a BIP155 serialized address.
//
static const uint8_t chainparams_seed_main[] = {
0x01,0x04,0xd4,0x38,0x29,0x3f,0x00,0x00, // 212.56.41.63
0x01,0x04,0xc2,0x8c,0xc6,0xb0,0x00,0x00, // 194.140.198.176
0x01,0x04,0xd4,0x38,0x29,0x2f,0x00,0x00, // 212.56.41.47
0x01,0x04,0x90,0x7e,0x93,0xa5,0x00,0x00, // 144.126.147.165
0x01,0x04,0xb0,0x7e,0x57,0xf1,0x00,0x00, // 176.126.87.241
0x01,0x04,0xd4,0x38,0x29,0x3f,0x55,0x08, // 212.56.41.63:21768
0x01,0x04,0xc2,0x8c,0xc6,0xb0,0x55,0x08, // 194.140.198.176:21768
0x01,0x04,0xd4,0x38,0x29,0x2f,0x55,0x08, // 212.56.41.47:21768
0x01,0x04,0x90,0x7e,0x93,0xa5,0x55,0x08, // 144.126.147.165:21768
0x01,0x04,0xb0,0x7e,0x57,0xf1,0x55,0x08, // 176.126.87.241:21768
};
static const uint8_t chainparams_seed_test[] = {
0x01,0x04,0x01,0x02,0x03,0x04,0x00,0x00, // 1.2.3.4
};
#endif // HUSH_CHAINPARAMSSEEDS_H
#endif // DRAGONX_CHAINPARAMSSEEDS_H