Why not have all the forgers constantly throwing around tiny, microscopic amounts of Nxt between each other in order to randomize the account balances?

As I understand it, the basic idea now is that you hash all account balances, that hash basically produces a random number which can be used to pick which account will be forging, correct?

You'd have to expand how many units it can use but what if you expanded the Nxt units so that you could have units of 0.00000000001Nxt.. or whatever, tiny amounts.  2*10^-6 would cost 1 Nxt per year.  So I say maybe 1 millionth of a Nxt.  Make the hash sensitive enough to that tiny differences between inputs can wildly swing the output.  Point is, you guarantee that there will be account balances constantly changing in a way that can't be predicted.

Every block, each forger random chooses how many Nxt to send around and each one sends some tiny random amount them of them to the account of another randomly chosen forger on the network.  If a forger has not been sending these tiny amounts of Nxt around, kick him out anytime he becomes one of the top 10 or 100 or whatever forgers in line to forge, maybe also exclude him when choosing who to send that tiny amount of Nxt too.  For that matter you only need a few accounts doing this to randomize the accounts balances, and no one can predict which accounts will have which balances.

Then you select the next forger off of the top of the queue, use the hash of a block 10 blocks ago, (after all 10 blocks to confirmation right?) to pick the 10th forger in line, then do it again every block.

Now you only know 10 minutes in advance if you are going to forge and it also only requires losing the ability to forge with Nxt for 10 minutes in advance.

IIRC this functionality is already there: https://bitbucket.org/JeanLucPicard/nxt/commits/cc6472a9de4499cf0b1ac24e041c08a6f4781d58?at=feature/tf

Sure.

raw = to-be-verified aka to-be-agreed-on

The problem with raw transactions are: they are the things we need to find consensus about. That is why we need blocks. Blocks represent the consensus on which transactions occured.

But: since we have not found any consensus about these raw transactions they can be added or removed at will. Why? Because we have not agree on them yet, because there is no block verifying them. I hope that is clear.

So, an attacker could add raw transactions into his pool of available raw transactions and therefore increase his probability of bundling them into a block that one of his accounts can forge.

A new forging account F is created by at least two transactions (3 NXT need in total):
1) funding (2 NXT to F)
2) public key creation (1 NXT form F to somewhere else)
=> F still holds 1 NXT and is able to forge in 1440 block from 2)

Because of that, an attacker could carefully design transactions that create accounts that will forge in the future.

So, this attacker could design raw transactions and shuffling existing ones and his artificial ones until he can a row of blocks that is long enough for his purpose.

Don't know anything about SkyCoin, but Emunie's website has been a graveyard and the natives are getting restless and are reporting lots of bugs, connection issues in the forums there. One delay after another and there's only one guy coding everything. They have promised a launch date at the end of March/Early April that I would not be surprised to see get postponed again. Everyone who has invested better hope Dan (lone programmer) doesn't get hit by a bus because the whole thing is still closed source.

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k₀ but also k₁ and k₂ and ... and k_limit-1 representing the next in the what I would call forging queue.

k₀ is the best, followed by k₁ and so on.

Often faulty, our old 87.230.14.1

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Yes, I know.
Nevertheless, you could use the implemented function for both scenarios.

Something like that. Different variations r possible.

But I think whether we treat that list as "ordered" or not *could* make a difference (so that needs to be considered).

This ends up being important to the "lottery" AT (and others that might follow it) as we need to be confident of the "randomness" of "tickets".