So "selectivity" is how many nodes are "qualified" to forge next (whether there is 1 best one or x best ones).

Randomness really comes from "selectivity" as the more "selective" we make TF then the "less" random the forging gets (unless forgers machines are off or lose internet connectivity).

Great idea - 1 NXT per message (will keep the forgers happy).

Agreed - so the remaining issues are of selectivity (does that bias things?) and then of randomness (unless we want another way to generate that).

Also the *effectiveness* of TF (in terms of quick confirmations) is going to be determined by this (as we can't easily stop "flooding" attacks - but widening the number of IP addresses will make those attacks harder).

Yes - so I think what are looking for is some sort of balance between "encouraging account splitting" and "how much advantage that would give you" whilst at the same time having as much "randomness" as we can get.

No - not breaking cryptography - just trying to work out the right balance between "predicting the next forger" and "knowing 100% the next forger" (if you can predict say 2 or 3 then you broadcast your tx to those and you should get an almost instant result but if there is "very little doubt" about who is next then apart from making it easier to *attack* the next node you have a problem with getting "random" things like "tickets for a lottery").

Exactly - this seems to have been misunderstood.

And this is the *concern* that I have always had about the "penalty" approach (as it might actually *help* with this - the simpler the algo the harder to game IMO).

Yes - this is basically what I modeled in code and mthcl in math (not considering the proposed TF but just the existing approach).

Of course any *model* is just that (so it may not be "good enough" to reflect the *reality*).

Yes - that was my understanding from my own modelling.

Still the issue of "randomness" is a key point that I would like to have checked (i.e. how "random" is the block # 1440 blocks in the future).

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".

I think that the idea for TF (maybe not as so far currently has been implemented) is that at least 2 or 3 accounts should have "the same value" (so there isn't a *best* one).

The purpose of that idea is to *inject randomness* that might otherwise mean you could predict too many blocks ahead (it of course results in more forks with latency and network topology being the final "deciding" factors).

Okay (and you did *ask for it*) - take a look at http://ciyam.org/nxt/nxt_crowdfund.html and in particular the "functions" section (those are some proposed Nxt AT API functions).

You can basically think of an AT as a program that owns an account (the AT account which only it controls).

As much as possible the AT account should have all the rights that a "normal" account does (although whether we will let it "create other ATs" initially is something we'd have to consider).

To "sandbox" an AT it will have to use a Nxt AT API (so it doesn't have access to the "full Nxt API").

Yes - I am.

Indeed - and this is why any such "behavior" for a "severe fault" needs to be clearly "documented" (so the "buyer" can "beware").

No doubt there is going to be a business for creating/validating ATs and even "insuring" them.

It will just be a special kind of transaction - but basically you'll need to use some sort of "form" to plug in some values (such as how much memory it needs) then the "machine code" and "initial data" bytes would need to be pasted in (yes - it will be a bit like "voodoo" at first - much like Bitcoin "raw transactions" are).

Very good point - in particular this is why my design is to imitate a very simple "instruction set" (rather than aim at "higher level language" although I foresee this will be added down the track).

Bugs can (and will) occur. In particular there will be the question of what to do upon a "fatal error" (say an attempt to access memory that is *out of range* or to jump to an address that is *invalid*).

I have suggested in my spec that we might want to have some "flags" to cover these scenarios in the creation of the AT itself (such as "restart on malfunction").

Understand also that AT will be able to effectively do "multi-sig" in the following way:

1. Create an AT and send it funds which it will return after x blocks if required conditions are not met or send funds to another account if conditions are met.

2. The AT is given x account ids that it knows about - to "sign" each account just sends an AM to the AT. Once the AT has *enough* of these AMs (from the required accounts) then it can *release* the funds to the "destination account".

The beauty of the AT approach is the rules don't have to be as simple as 3 of 5 (you could do all sorts of things such as say "weighting" the accounts).

So I hope your new efforts are going to be rewarded (hint to whales) and that you will also consider modelling the BCNext proposed TF approach (with "penalties" which you can ask CfB about).

This sort of scientific work is very beneficial for the Nxt project IMO.

Basically AMs could be used in order to change an ATs behaviour (but you can't *change the code itself*).

No need to "delete" as once its balance is exhausted (by running) it can just be removed from the block chain (like old AMs).