That's actually pretty darn clever! He has created a trivial implementation of a vector clock. Basically the "trusted nodes" are really time keepers marking what happened in what order. I'm assuming they are known in number and non-anonymous nodes.

In the case of a network partitioning (intensional or otherwise) the known trusted nodes have to be partitioned as well. In this case, since you know the total number of trusted nodes, you have an additional piece of information to use in reconciling chain forks. The number of trusted nodes marking time on each fork. This defines the center of the SolidCoin universe.

If 90% of the trusted nodes are marking time on one fork, and you are hammering a fork with 10% of trusted nodes marking time, you will probably lose when the partitioned networks recombine. But fortunately, for you, that should become apparent as you see timekeepers drop off your chain.

so it sounds like difficulty is increasing as planned.  The problem was initial design having initial difficulty of 1.  And that doesn't seem like that much of a problem.  It does heavily favor whoever was mining for these initial low difficulty rates.  As throwing huge amounts of processing power at the chain would not increase difficulty heavily.

If the initial difficulty was 10, the difficulty right now would be 10x what it is now.  If it started at 100 it would be 100x what is now.  This was probably an unplanned problem due to the variables stated above.

The only problem I see with having the hard 10-15% difficulty increase cap is the chain does not adjust well to large amounts of processing power being added.  That coupled with the uneven % increases in the negative direction, and the "attack" mentioned a few posts back of strobing/throttling a large botnet onto the chain seem like it could become a problem.  Not so much a huge problem, just that a large amount of processing power could be used on the chain for a longer amount of time due to the retargetting scheme - which would mean potential attackers could "harvest" more out of the chain without affecting the difficulty as much.

I also don't think the huge # of stales at the start was an attack.  It more sounds like the extremely low difficulty of 1 coupled with a huge influx of unexpected miners caused a lot more problems than expected.  If you are generating a block every 1s - it's going to be real hard to keep the whole network on the same chain.  Propogation time alone of the blocks would probably take longer than generating a new block - and that was more the main issue it seems at the start of this chain.

As for central authority and % skimming of generated blocks that's a whole other issue not related to security, and more related to trust and design.  As people have been posting, that really is an issue with trust and with who controls that wallet.

Claims of 51% attack preventions - I don't believe there is enough evidence or proof here to refute or back up those claims.  But I'd be wary of assuming this is true without proof.  But I also wouldn't go out of my way to say it's not there.... There is no proof for either side to be true, just claims that their side is true....  Show me a 51% network control double spend and I'll believe it doesn't have protection, or show us/explain to us the code of how a 51% attack couldn't succeed.  But without proof on either side my bias would be to assume it isn't true because there's no gain, only potential loss by assuming it is true without proof.

edit: difficulty started at 8? or you could think of it as difficulty starting at 6.03 after first retarget?
6 * (1.13^69) = 27578.0688

And why start difficulty at 8 instead of, say, 1000? Well, gifts for all fanboys 24/7 on IRC ready to start mining from second 0.
You can't at the same time say you're spreading early coins amongst "thousands" of early adopters and be surprised that a difficulty of 8 gives super fast blocks.

Someone must be gaming the difficulty.  Maybe the "pulsing attack" others have mentioned.

Difficulty adjusts ever 240 blocks (2 per day, 3 minute target block = 240 blocks per 12 hours).

I am showing 17873 blocks and difficulty of 2791
Initial difficulty was 8.

17873 240 = 74 adjustments (truncating the fraction)

The network has continually been behind the 3 minute target so every adjustment should be max upward.

If max adjust is 10%.  8 * 1.10^74 = 9205
If max adjust is 13%.  8 * 1.13^74 = 67,747
If max adjust is 15%.  8 * 1.15^74 = 248,159

Actual difficulty after 17873 blocks (74 adjustments) is 2791 (a mere 348x original difficulty).

What gives?

There were lots of invalid blocks, but only because valid blocks (thus valid SCs) were being created so fast.

On this we agree.

This answer?
6 * (1.13^69) = 27578.0688

I give a Magik a +1 for remember the first difficulty drop and working off that 6 w/ one less transition.

Only one small problem....
Difficulty isn't 27,578 right now.  

Other than that small glitch your right, it makes perfect sense.

Speaking of that difficulty drop.... WHY DID IT HAPPEN?  The first 360 blocks occured w/ average time of 2.2 seconds per block vs target of 360 seconds yet difficulty went down.  Got an answer for that one?  Since it is so easy and nobody needs source code anyways.

You actually going to read any of my posts? The answer is above.

What is worse:

1) A possibility of a 51% attack OR:

2) CoinHunter being the POLICE of your entire economy??! (and earning 10% of all coins to himself!!)

LOL

Last night price of small instance was $0.08 per hour.  400 instances would be only $32.  Amazon offers free computing time to repeat customers (I have 8000 hours of small instance time and I doubt I am what they consider a big spender).  They also offer volume discounts for major company buys.  Spot pricing was $0.025 per hour and looks like EC2 had almost 120 instances at that price (possible they could have had more earlier).  400 instances @ spot would have been $10 per hour.  Not sure where you are getting $100 per hour from? 

He may not have had 400 instances but one could easily run 400 instances for <$32 possibly even free. 

It *seems* that BCX's theory has so far proven itself: Block generation hasn't (meaningfully) adjusted, despite massive difficulty increases.