There's a few things going on - hence trying to clear up things.

1) Nodes
What:
Long standing dvc nodes - ideally placed on fast connections & configured with a large number of connections.

Why:
To allow new & existing clients to bootstrap quickly.  To allow a complete fall-back when other systems aren't functioning.

How:
Coded dns names in the code - that allow cname & a lookups.

2) Locators - client discovery
What:
Review the current infrastructure to ensure it's suitable for scalable growth.  
IRC, DDNS (DNS Seeding), Client cache

Why:
It's good to review where you are and where you're going.
DNS Seeding should be reviewed and checked to see if the current setup is optimal.  DNS Seed names (DNS entries) should be checked & updated - are we using the most appropriate record types, what's the change control process.  As you mention - does it fallback properly should those DNS Seeds be taken out? Can geoDNS be leveraged to help users download the blockchain from their closest neighbours.  Tech has moved on - DNS has improved a lot - with ipv6 more prevalent now - srv & locator records can be used and you have more granular control over the how & what.
geoDNS is now pretty affordable and no longer limited to the big-boys - it can make a huge difference to the blockchain startup/catchup time for end-users.
The existing locators aren't setup to gather & supply metrics - each DNS query, irc join is a statistic that's useful in gauging adoption, growth & measuring scale.

How:
Test, metrics, target goals for how this works.

3) DNS
What:
Using existing DNS names to make config & setup easier & simpler for end users.  

Why:
Long term success in pretty much all things comes down to making something accessible to end users.

How:
Update the way a handful of (1) are recorded in DNS, update the documentation for users telling them they can addnode=dvc.devcoin.me and you'll be up & running in no time.
Using something like dvc.devcoin.me is way easier than 15 addnode=abc.def.ijk.lmn entries when a user is complaining that its taken 20h for their blockchain to be downloaded.


I'm overly cautious when it comes to DDNS because there's risk - it's easy to pollute and as it's a centralised public resource it's an address book of hosts.

Not really - we're talking about 2 different things.
I'm talking about replacing the existing hard coded IP addresses with DNS based lookups - these authoritative nodes help bootstrap the rest of the network.
You're talking about the ddns DNS boostrap - which ultimately is a subdomain of the first.  It's a worthwhile pursuit - but requires infrastructure and a balanced distribution to be effective.  One of the reasons for IRC is that there already exists a well distributed network that can be used to leverage bootstrapping.

Thoughts for the use of DNS in dvc.

Suggestion:
(1) Pick a DNS name that will be the root name used by users & the dvc client for resolving seed nodes (long standing core dvc nodes that can help bootstrap new dvc nodes).
(2) Use a DNS provides that's dev friendly, supports round-robin (RR) DNS entries and ideally already has (or plans to implement geoDNS) and under dvc "admin" control.  You don't want to use DDNS (Dynamic DNS) for security reasons and getting into the whole IPSEC DNS is a can of worms.

Why:
Simpler bootstrapping for new & existing users.
Simpler management - host IP addresses will change over time (hosts go down, get moved, etc) - currently this requires a code change.
(2) allows for the load to be distributed & using geoDNS allows for locally served updates - providing a quicker catchup & bootstrap time.

How:
RR DNS entries are DNS A records that map from a hostname to an IP address.
The existing dvc config file can be used with the DNS entries - using addnode one or more times using the dns name from (1)

The dvc client code can be updated to take advantage of the new scheme in a more intelligent way.
In this case - the code does a DNS lookup for all records using (1) - resulting in a number of DNS A records.  Each of these is then used the same way addnode currently works. You can see an example of this using nslookup & using "dvc.public.txn.co.in" where you'll see 2 records returned.

In addition - as it goes through each returned DNS A record:
(a) it checks you have an IP from the lookup (making sure you have an A record & node something else like a cname)
(b) the IP is valid & the host is responding - it records the lookup & the time the lookup happened
(c) every n minutes (driven by the config file or the cli - ala devcoind dns-refresh) it repeats the cycle.  This allows long standing nodes to refresh & reload these addresses without restarting the daemon.

With Round Robin DNS you can do that - but with ipv4 it's manual - so you create A records for node.devcoin.org for each IP. 
ipv6 allows more of a dyamic lookup allowing more of dynamic approach - take a look at the srv records here - http://www.debianhelp.co.uk/dnsrecords.htm

Aye - you can plug in host-names instead of the ip addresses - giving you a little more flexibility with moving nodes about.
The lvl of security is about the same - although I'd suggest adding extra logging for the name -> IP lookup - so you can debug issues should they arise later.
Risks..
About the same as now - to subvert you'd have to add a hosts entry - rather than currently (with ip) you'd have to add a route.

Resolving a dns name to an IP shouldn't cause a crash if you properly wrap the call.
Robust coding.. is robust

You control the zone - so assuming you use a secure approach to management - then lookups will be under your control and done in a responsible way.
I think the terminology has been confused a bit.  The nodes, from what I understand are just full time nodes running on a server with a fast connect and configured to allow a high number of connections to help bootstrap other nodes - ala seed nodes.

You can use DNS round-robin to make config easier for people.  They can just point to a single name - and DNS is setup to round-robin or to use an algo to distribute traffic over the set of DNS records - distributing the traffic a bit.

As IPV6 isn't enabled in dvc (from what saw after a quick lookup) you can't use anything smart with srv records.

With geoDNS for ipv6 or normal IP - you can config things a little smarter as many of the geoIP setups allow you to group a set of DNS records per geo zone.
This would allow EU users to lookup a DNS entry - and get back a subset of the records - so they have a faster bootstrap time than connecting all over the globe when bootstrapping the blockchain.

The critique started way before they "shipped" - they received a lot more attention because they took the stance of avoiding self-promotion and wanted a customer to comment.
I don't think they handled the launch particularly well-

It can be - but often it's not.  So far bASIC & BFL (I've not seen any posts about people asking for Avalon refunds) - both established companies have stumbled over the refunding - so in the btc hw world - proper record-keeping appears to take 2nd place.  It's understandable - they're smaller ops and investment in customer management systems take time & energy.
I've built these systems and they can be a nightmare when it comes to adjustments to orders.

From a business perspective - I don't blame Avalon for wanting to keep things simple at the moment.


heh - yes & no.  There's an argument (not that I agree with it) when it comes to startups that customers should love or hate you.
The idea is that its better to have people polarised than to have them feeling "meh" - that way you have right kind of attention - negative attention becomes an indicator that you need to change.
I'm more conservative - you can't please all of the people all of the time - it's better to stick to some principle that matters, hope you have the right kind of attitude to your clientbase - and do your best by being upfront.

heh - if you look take the time to look back (and using the excuse that there's no need to look back - because you "know") - it's been far more than just 2 days.
Look at bASIC's refunds - it took time because orders aren't clean or simple - it's a nest of vipers where somebody orders one, then another, paying part with one thing (btc), another part with something else (like a cc).  Allowing "deposits" adds complexity - somebody wants to pay 10%, somebody else wants to pay 20%..
When it comes to fulfilment - you then need to chase up & reconcile who's done what. 

In business - every customer feels they're special, that their case is unique.  From the other side of the fence - a business that has to deal with 600 "unique" customers ends up wasting time.

Why would they?
They've taken months of abuse on the forums - finally have shown their true colours by bringing kit to the marketplace.
Any serious customer into btc will have the coin to hand or made arrangements to have coin in time for batch#2
Demand will be far higher than the size of batch 2 - so they can cut out any headaches and ask for upfront payment.

heh.. I know - wouldn't it be great if you could, you know - exchange coin for cash - or like.. buy other services you might need with it..
https://en.bitcoin.it/wiki/Trade

If they ship, if the specs are what they hope and what else is hashing on the network.  asicMiner are out there also.
Each hw round Avalon go through gives them an opportunity to bring down costs and improve on their design - so in the same time frame there's a chance for the units themselves to improve.

Now they have shipped - they're the only real baseline we have.

heh - now there's an idea.. instead of a salary.. you get a box that generates your salary

The 2nd image here - https://forums.butterflylabs.com/bfl-forum-miscellaneous/735-avalon-countdown-discussion-thread-4.html#post12163 - indicates there's others who have an Avalon also.

Respect & +1 cedivad - real men aren't afraid to be corrected - stand up for what you believe.
I don't fault Avalon for trying to do things the way they feel is best for them - I don't think they've handled their customers particularly well recently - but they've been better than many and it turns out substance over hype is a better suit for how they want to be seen.  At the end of the day they've come through.  Nice job.

Looks like Jeff received his package...
Should I hold my breath waiting for those crying scam to apologise?

It was designed to resist HW scaling - which it does - very well.
Anybody with just an inkling of how computers work understand that's it's virtually impossible to design an algo that cannot be scaled.

A coinbase isn't just about the blockchain or mining - in my mind, what makes a coinbase successful, is the community around it.  Having a diverse group of people interested in it, building projects, large or small, to use it or exploring how it can be applied to their own interests.
There are a few large scale projects being developed at the moment, there are lots of smaller projects being worked on - no one project will turn it around overnight - infact I hope there isn't one project that can make or break any coin.  Over reliance on one single entity is a path to failure in my mind.

On litecoin we've been working on a number of things in parallel:
We're working with the community to find out how they see it and what they'd like to see - not just with the blockchain and the client, but with the infrastructure around it. 
Do they get the support they need, are they seeing the projects & services around it that they want? 
Where they see it today and what they'd like to see from it tomorrow.  Are there the right kind of hooks - that allow them to try out their own ideas with it?
Meanwhile we've been building some of the things we feel are missing for the coin and building some components that allow others to integrate with it a little easier.

As a community - we're not going to get these things right all of the time - but we're trying to build things up in the right kind of way that we (a) have a measurable goal, (b) measure the effect of that goal, (c) learn from it.

The OP has his own agenda - which is cool and I respect his passion in trying to bring TRC mainstream.  What I object to is building contrived arguments against other coins just to further his own goals.  You don't build a good solid coin or a community behind it by throwing mud - you do it by being better. 

Unless you know the actual projects being developed - you have no idea to which coin they're targeted.  Frank is involved with several litecoin related projects.
Seriously - its ok to say "I don't know" - people actually respect you for for it.

heh - it's good.


aye.. well.. umm... nuff said really

There are new devs that now have commit access to the ltc repo.
Coblee is on-board with a few of us working on the code and rolling in updates - many of which are in test and we're aiming to start more regular release cycles of the client.
We're being careful to ensure we can provide a clean upgrade mechanism for users as we build new functionality and roll in important changes from the bitcoin source.


Yes - many, not all, developers on bitcoin set a high standard.  We're aware that some like to compare "gold" to "silver" - we think there is an appropriate niche for both.
With Litecoin worked closely with the bitcoin developers in the past - adapting the niche we think we service - we look forward to continue doing so as time unfolds.


That's an unfair and invalid argument ck - Coblee did a Satoshi for a number of personal reasons - he's around and reachable by the current team - but he doesn't have time to commit with the everyday dev.  We do talk with him when it comes to major changes or for brainstorming - but we also have scope to bring about change.
Gavin stepped in and did a great job of moving bitcoin forward - building upon a solid foundation and helping to turn it into what bitcoin currently is today.  Give us a chance to see if we can do the same for litecoin.

There are limited services currently with ltc - and that's largely our responsibility to work out and fix.
This is something we are heavily into at the moment and I think over the next few months you'll find a lot more possible with LTC other than speculating or hedging against with btc.
On btce ltc is heavily traded - with very healthy volumes which I think is a very good sign.

We're also looking to deal with a number of hostile actions by some who believe that btc should be the only coin.
In the past few months the blockchain & many of the pools have been attacked by those who believe it should be taken down - sadly it appears that one of the contributors to the bitcoin code also have it out for litecoin - which tarnishes the image of not just bitcoin but all cryptocoins. 
We've weathered these attacks pretty well I think - we've learned a lot and now in a more solid position to take Litecoin to a new level.

Humm - the exchange isn't loading any more...

did having trc as a currency make the exchange bankrupt?