markm, please elaborate on the commitment you mean? or PM me. I'm tryna help and BQC is gon be big.
Well actually there are two layers of "fallback nodes".
One is the "DNS seed" layer, in which hostnames (host.domain.tld) are coded into the clients instead of IP addresses, so that who-ever controls the domains those DNS seed hostnames are in can point the hostnames at "stable nodes" in the (hopefully rare) event that a "stable node" is somehow forced, despite its best efforts, to change its IP address.
This layer provides the client with fallback that can be changed to point to different nodes without having to change the client and have everyone install a new client.
The second layer does require a new client release to fix, thus it is where only the most determinedly stable nodes of all should be coded in, since it is the final resort layer, only in fact resorted to if not one of the hostnames in the DNS seed layer resolves to an IP address that actually is still running a working node. This final resort is a list of actual IP addresses, thus it needs nodes that are able to ensure their upstream ISPs and such are extremely unlikely to ever change which IP address is assigned to that node/machine.
The nodes of that bottom layer need to have stable IP addresses, not just stable presence online, reliably open incoming port, ability to have a huge number of connections (so many that bitcoin nodes of this kind for example have been known to crash from lack of RAM if they have only four gigs of RAM) and enough bandwidth to supply the entire blockchain to lots of new user clients all at once.
It would make sense to me that the people who control bbqcoin.org, bbqcoin,com and bbqcoin.net (maybe especially the .net since .net top level domain is for network infrastructure type of domains?) should take on the responsibility of ensuring that DNS seed hostnames on their domain are kept up to date, meaning, are changed to point to a live backbone-node if the backbone-node they point at dies or flies by night.
That is a pretty cheap responsibility, since it need not involve any ongoing human workload if it were done by someone who hosts their own DNS servers for the BBQcoin domain they are administering. (Scripts could modify the DNS in accordance with watchdogs that check the nodes pointed to are alive.) For someone who uses third party DNS servers it would involve having to navigate whatever stupid GUI-website type interface their DNS provider makes available to them through which to modify DNS records.
(Unless their DNS provider provides an API
Look into that...)
Merely keeping a bunch of hostnames on a domain pointed at serviceable backbone nodes is trivial compared to actually providing a backbone node, even one placed only on the DNS seed layer due to not really being able to be sure it will be able to stay at the same IP address consistently over the long term.
For DeVCoin, we have coded into the client five hostnames on each of two domains: dvcstable01 through dvcstable05 on each of devcoin.org and devtome.com
Someone though suggested one could use just one hostname and plug in however many IP address one chose per hostname.
I preferred separate hostnames because I wanted to be able to ssh and sftp to a host by name and also did not want to have to use a 3rd party web-gui user-interface to type in every IP address twice, once into the many IPS per hostname hostname and again into each individul host's hostname.
However, looking at / caring about machine work rather than human data-entry-clerk work, apparently the client could find connections faster if it could get lots of IP addresses with one hostname-lookup and loop through them instead of looping through hostnames doing a DNS lookup on each one.
Using two domains was in case the admin of one falls under a bus. Accordingly the hostnames on both domains point to the same hosts in case the DNS-provider of one domain falls under a nuke or other WMD. We only actually have four backbone nodes so all four's IPs went into the last resort IP numbers list and the hostnames 01 through 04 point each to one of the nodes, the fifth name not being populated yet but being looked up by the client hoping we do get to populate it some day.
-MarkM-
