One decent machine should be enough for a single DNS seed server that can run both Mainnet and Testnet. I rather avoid the costs of running additional machines.
I noticed inability to connect to last working seed node mainn-seed.grinnode.live from Germany, also I dont see last working IP (85.10.201.143:3414) here Grin Blockchain Explorer and one of IPs (217.173.235.116:3414) uses old Grin 5.0.4 node @mcm-mike .
grin seedcheck command returns this result for list above for now:
[
{
"url": "main.gri.mw",
"dns_resolutions_found": true,
"success": true,
"successful_attempts": [
{
"ip_addr": "80.90.182.173:3414",
"handshake_success": true,
"user_agent": "MW/Grin 5.4.0",
"capabilities": "HEADER_HIST | TXHASHSET_HIST | PEER_LIST | TX_KERNEL_HASH | PIBD_HIST | PIBD_HIST_1"
}
],
"unsuccessful_attempts": []
},
{
"url": "grincoin.org",
"dns_resolutions_found": true,
"success": true,
"successful_attempts": [
{
"ip_addr": "195.201.2.51:3414",
"handshake_success": true,
"user_agent": "MW/Grin 5.4.0",
"capabilities": "HEADER_HIST | TXHASHSET_HIST | PEER_LIST | TX_KERNEL_HASH | PIBD_HIST | BLOCK_HIST | PIBD_HIST_1"
}
],
"unsuccessful_attempts": []
},
{
"url": "mainnet.grinffindor.org",
"dns_resolutions_found": true,
"success": false,
"successful_attempts": [],
"unsuccessful_attempts": [
{
"ip_addr": "91.97.173.85:3414",
"handshake_success": false,
"user_agent": null,
"capabilities": null
}
]
},
{
"url": "main-seed.grin.money",
"dns_resolutions_found": true,
"success": true,
"successful_attempts": [
{
"ip_addr": "192.227.211.112:3414",
"handshake_success": true,
"user_agent": "MW/Grin 5.4.0",
"capabilities": "HEADER_HIST | TXHASHSET_HIST | PEER_LIST | TX_KERNEL_HASH | PIBD_HIST | BLOCK_HIST | PIBD_HIST_1"
},
{
"ip_addr": "64.69.36.59:3414",
"handshake_success": true,
"user_agent": "MW/Grin 5.4.0",
"capabilities": "HEADER_HIST | TXHASHSET_HIST | PEER_LIST | TX_KERNEL_HASH | PIBD_HIST | BLOCK_HIST | PIBD_HIST_1"
},
{
"ip_addr": "107.175.115.89:3414",
"handshake_success": true,
"user_agent": "MW/Grin 5.4.0",
"capabilities": "HEADER_HIST | TXHASHSET_HIST | PEER_LIST | TX_KERNEL_HASH | PIBD_HIST | BLOCK_HIST | PIBD_HIST_1"
}
],
"unsuccessful_attempts": []
},
{
"url": "mainnet-seed.grinnode.live",
"dns_resolutions_found": true,
"success": false,
"successful_attempts": [],
"unsuccessful_attempts": [
{
"ip_addr": "217.173.235.116:3414",
"handshake_success": false,
"user_agent": null,
"capabilities": null
},
{
"ip_addr": "213.239.217.14:3414",
"handshake_success": false,
"user_agent": null,
"capabilities": null
},
{
"ip_addr": "176.9.86.219:3414",
"handshake_success": false,
"user_agent": null,
"capabilities": null
},
{
"ip_addr": "85.10.201.143:3414",
"handshake_success": false,
"user_agent": null,
"capabilities": null
}
]
}
]
to make initial sync work you need to edit ~/.grin/main/grin-server.toml and specify peers_preferred = ["main.gri.mw:3414", "grincoin.org:3414", "main-seed.grin.money:3414"] under [server.p2p_config] for now.
Will wait @stakerV and @wiesche to check their nodes and let’s make at PR to main repo.
The Grinffindor DNS seed (main,test) is working and has been tested.
Since there are very few seed nodes, could the foundation build its own nodes, for example, by establishing several super nodes globally, selecting well-known large cloud server operators, choosing high-bandwidth servers, and having the foundation be responsible for maintaining these super nodes?
Grin has no foundation, only some developers who is in favour to launch nodes to serve clients.
Just wondering who you mean with “the foundation”? If you mean the Grin Governance Council (GGC), those are just a bunch of volunteers and regular community members. Grin is quite minimal, in practice even a DNS seed node only needs “reasonable specs and bandwidth”, see original post by Igno.
So best to keep things minimal and decentralized and let trusted community members volunteer their DNS seed nodes. @JasperKai We could use a few more of these seed nodes if you are willing to set on up?
On a side note, see how he recommend setting max_peers = 250, quite the optimist ![]()
Indeed, I noticed big slowdown of sync at server with low RAM amount (like 2GB), especially at PIBD step, also high load on disk at this case, even with disabled inbound peers.