[feat] Ability to manually designate a delegate as a 'failsafe' seed node in xcashd

Current Behavior
Currently stand alone xcashd nodes rely completely upon the team managed seed nodes before they can successfully start.

Possible Solution
The ability to manually designate a delegate from the command line to allow stand alone nodes to start when there's an outage of seed nodes. For lack of a better term, a disaster recovery (D/R) method in situations where all team run seed nodes are down or denied service for whatever reason. This would go a long way towards decentralizing the network and allowing it to continue in either D/R situations or if DDOS incidents occur.

Context
Currently, without any seed nodes online, I am not able to start a local node successfully. Relying upon only the team run seed nodes in order to start up a local xcashd is too much centralization. Allowing us to designate one or more "failsafe" delegates to act as seed nodes would help maintain stability of the network.

[zachhildreth]

Hi @CygnusMiner
I do like the fact and acknowledge that this is a "centralized and weak" point of the DPOPS design. This is why I say its only 99% decentralized at the moment and will be 100% at some point. I had a solution for this but it was too overcomplicated and did not have time to simplify it or release it during alpha beta

The problem with just assigning someone as the seed node is with only 1 seed node they could technically say the top 50 delegates are themselves only and produce infinite blocks. With multiple "other" delegates this would be more secure though.

I will leave this open as it should be a good discussion page for the community and something we should address in the testnet as one of the first few issues. Their are many ways to have backups like designated trusted members or some sort of DBFT solution. The issue is you dont actually have the peer list since that is gotten from the seed nodes every block, so maybe some sort of saving of the list would work as well.

"...maybe some sort of saving of the list would work as well."

I like this idea. A method of keeping a trove of good delegates that you can then randomly select from in a 'down situation' would be much safer than, say, asking on discord who has a delegate available and possibly falling into some sort of architected chain manipulation trap. Constantly keeping that list updated will be key, and the list probably shouldn't be used except if in a disaster where all seed nodes are down. They would have to be preserved post process exit so that you don't lose your cache at restart.

I suppose the next question should be if you update the cache once you're successful in starting up w/o seed nodes, or do you keep the list static until the seed nodes are back online. The concern here being the chance that you've picked a malicious actor who gives you a set of bogus delegates that you've then replaced your good ones with. 🤔 The drawback of keeping it static, of course, is that you no longer have the ability to add in new delegates as they come online and to remove old delegates if they go offline.

Also, caching delegates while the daemon is running doesn't help the situation where you're trying to come online from scratch during a seed node outage.