Initially the clients connect to a random subset of seed nodes.
Then they acquire peers.
The desired number of connections is 20.

PS: delegates desired number of connections is 50 .
These values could be modified by the users at runtime.

Something is brewing in the background...you dastardly fools!    D:<

Lets hope it will be properly announced this time.

First of all, it is my understanding that all clients will detect certain easy-to-spot misbehaving by delegates -- automatically, and downvote them accordingly. Is the opposite also true? Will longstanding well-behaving delegates be automatically upvoted?

There is no automatic voting.

What constellation of conditions is necessary for a delegate to reach the top 101? Does that list tend to stay the same, or it's always rotating, possibly enforced by the system?

You need people with stake (read BTS) to vote for you. Top 101 by amount of stake voted are delegates.

Is there some 'delegate explorer' website out there?

bitsharesblocks.com (thanks to svk)

Lastly, pertaining payouts, it is my understanding that delegates get paid in bitshares, correct?
How many bitshares will that be -- does it depend exclusively on the burn rate, or also something else?

Depends on the payrate. It is visible in bitsharesblocks.com

I read somewhere that at (that) the moment, a delegate is expected to get about $2500 equivalent in BTS, presumably for a month of service. Is this more or less right?

Depends on the exchange rate of BTS. Numbers vary.

If so, as an extremely well versed systems administrator who's fully comfortable with securing unix systems to high grade, what prevents me from setting up 100 delegates (I realize many/most would not make it to the top 101), wait for them to become stable and accepted in the network, and sit back & watch the money coming?

Delegates are voted in by stakeholders  (owners of BTS).

This looks like a reasonable solution.
However I'd like to point out that a delegate should NOT rely only on it.
As these nodes are public and known they are vulnerable to the same attack.
If these nodes are taken down all delegates exclusively using this solution will be affected.

I'd recommend every delegate to have at least 1 "relay" node in standby mode (or a manually activated backup delegate) that can be activated in case of an attack.

As the cost of setting up a relay node is minimal and its configuration trivial I do not consider this an issue.

I recommend every delegate to set bter_trust_level to 0.0 in the config file

Given the recent events this might be a good idea.
Delegates are free to modify the configuration as they see need for it.

EDIT: Just to note that currently bter returns an error so it is ignored by the script anyway

Quote from: Come-from-Beyond on February 10, 2015, 05:25:40 pm

Quote from: emski on February 10, 2015, 05:22:03 pm

They are not interesting anyway...
Anyone could create such hardware and require users to purchase it in order to use the system.
It is useless for bitshares as its goals are WIDE adoption and custom hardware prevents that.

Right. Let's assume that Sybil attack is mitigated and look for other weak spots.

Hold on. Can that be mitigated by making changes to the software codes?  I think something like DNS with reverse lookup and certificates can help.

Hold on! Where is the privacy ? Dont touch that.

Quote from: emski on February 10, 2015, 05:07:37 pm

And what is that company ? You can PM me the name...

The same company that is developing the hardware that supports blockchain tech.

Is any of the following true for your proprietary solution:
Your proprietary solution require users to purchase your hardware.
Your proprietary solution decreases privacy .
Your proprietary solution decreases usability .
Your proprietary solution involves POW .

What is an "anti-sybil solution"? I know what sybil attacks are.

It would be difficult (or restrictive for end users) to implement such solution for bitshares.
I'm not sure if there are plans for such anti-sybil solution. I cant remember it being discussed at all.