Basically because they decided to "pay themselves" with them in their "launch" (giving their employees an incentive to try and get people to "speculate" on them).

Quite likely BCNext studied Ripple closely (maybe even worked on it) and thought PoS could be a less "centralised looking" method of consensus than the "federated servers" model.

Anyway - at least I now have a much better understanding about "what the plan" is (or at least was) - I guess it is now up to the community to decide whether to follow this plan or create a different one.

Ripple's tx performance will drop with the number of nodes (or federated servers or gateways) - and with TF and forge leasing Nxt's performance will improve.

Understand what isn't relevant is "little people forging on their little computers" and I'm guessing it was never part of the plan (thus the penalty thing as much as anything is to discourage people who "don't belong to the club").

But otherwise *yes* it would appear the plan was always to try and be more like Ripple than Bitcoin (and BCNext's comment that he didn't want NXT to really be worth anything is very reminiscent of Ripple's earlier statements about XRP being like "stamps").

A quote from CfB that I think is pertinent:


So just having "more nodes on the network" is not what he nor BCNext seem to be really concerned with (nor in limiting forging power).

My guess is that what they really want is just a few large players working as a tight group to control the network (it would explain the reason why so few were included in the IPO also - things like 21 BTC are just red herrings to my thinking).

Wasn't included by who?

That is my point.

We are still trying to work out what exactly is required for TF to work properly.

The purpose of penalisation is try and prevent some sort of advantage happening by "gaming" the system, however, I am far from convinced that 1) it will work and 2) that we even need it.

One reason is that TF is supposed to not favour one single "best forger" for one block but instead that there should always be x equivalent "best forgers" for any given block. So if you are wanting to "skip your turn" you don't need to "pretend your asleep" but perhaps you just send out your block *after* the others that are equally qualified to forge already have.

This situation becomes quite tricky when you think about network topology and is going to result in some nodes "penalising you" and some nodes "not" depending upon whether or not they think you broadcast your block "on time" (i.e. a race condition) and I am concerned it could result in more people "ending up on a fork" than not "penalising" at all (because if you are a large stake holder then you are likely to be forging more than once per day).

Probably not such a great idea when we consider the importance of decentralisation - what I would like to see is just a bunch of small independent pools (each with say a max. forging power of 1% or maybe 0.1% of all NXT).

This is why I would like to see some sort of "forging power limit" imposed.

Great to see people creating test cases - but it would also help if people created "extreme test cases" that "purposely try to break AE".

Devs unfortunately have a habit of only testing the "expected use cases" themselves (so generally you'd expect that you won't find a bug that way). It is when you do something "only an idiot would do" that you are more likely to uncover any flaws.

Simple examples of such "idiotic" ideas might be things like "0 value" bids/asks or other "out of range values" as well as edge cases to do with zero or potentially negative balances.

Don't just "test that it works" try and "test that you can't screw it no matter how hard you try".

Some bounties for "breaking things" might be in order also (hint to technical funding committee).

Certainly someone is going to have to explain to him how "cold storage" has to be "done differently" in Nxt (am also not sure if the "hash chain security" idea was still going to be added to AC as CfB and I realised that it could also be done via an AT).

For those wondering about a "hash chain security" AT let me give you a simplified example (using MD5 for readability):

md5( 'secret' ) = 5ebe2294ecd0e0f08eab7690d2a6ee69
md5( md5( 'secret' ) ) = 7022cd14c42ff272619d6beacdc9ffde
md5( md5( md5( 'secret' ) ) ) = 19ff59e135cce19e3493402cb3884628

You would create an AT that has the value '19ff59e135cce19e3493402cb3884628' hard-coded in it and load it up with "balance". You would then send an AM with an "output" account to the AT which would "lock in" that output account for the next x blocks (so that other AMs sent by would be thieves before that block is reached to try and change accounts would simply be ignored - you could also ignore such AMs unless they were sent by the AT "creator").

After "locking in the payout account" (and perhaps payout amount) you would then send an AM with '7022cd14c42ff272619d6beacdc9ffde' which the AT would hash and verify it equals the hard-coded value it currently has. It would then update that hard-coded value to '7022cd14c42ff272619d6beacdc9ffde' and release funds to the address that was previously locked in.

To repeat you would next use '5ebe2294ecd0e0f08eab7690d2a6ee69' and then finally 'secret' (you can make the chain as long as you like as it takes very little time to do thousands and even millions of hash rounds on modern hardware).

This gives you a 2FA built right into the blockchain (requiring the thief to not only know your private key but also your "hash chain key").

Am only referring to the "difficulty" question (not overall power to forge - they can divide up their NXT into multiple accounts right now).

Effectively that is the original TF idea from BCNext (AFAIK) - 2 or 3 (or 4?) accounts would get *equal* ability to forge the next block and those that *fail* are *penalised* for not doing so (am not quite sure if the penalty is intended just for those that fail to broadcast or what and maybe this is why I am not convinced about the *penalty* thing so far).

So if we limited the forging power of a single account to x then presumably the "difficulty" would become practically irrelevant.

"Running away with the chain" is simply going to come down to "how many blocks in a row" can a combined or individual forging entity obtain (the more then the more likelihood of an issue) and whether "by skipping their turn" a forger can improve their odds of causing trouble (where trouble means that 10 confirmations is no longer safe).

I guess the problem with TF is that we still don't know exactly what was intended and with "leasing your forging power" and the "penalty" idea it is actually even less clear (at least to me).

For example - if the "penalty" means that your client effectively "ignores the pool" then one can see that having a huge amount of "leased forging power" tied to one account is actually not so useful (as that power might be unable to be wielded for maybe a significant % of the time).

Hmm... I am not quite clear on what you are referring to as being the "latest target" - if this is something to do with "difficulty" then my understanding from discussions with CfB about TF is that it won't even be necessary to have that (I am not even quite sure why "difficulty" was even used at all - perhaps someone would care to enlighten me?).

https://github.com/ciyam/ciyam/blob/master/src/crypt_stream.cpp#L173

Although it is of course in C++ (if you search around you should be able to find it in C).

Am back from Hong Kong now (wasn't online at all for two days so have been busy trying catch up all afternoon).

As far as people wanting me to be a "core dev" I don't think it would make much sense as I am a C++ programmer not a Java programmer (and have only even looked at a small amount of the source code) so at this stage I will keep my main involvement to the AT side of things but may get involved with other things down the track.

As far as pools are concerned I think we are going to need them and without them we won't be able to create a "savings account" AT (which I think would be something fairly attractive from a marketing perspective).

I had stated before that my preference for limiting the power of an individual pool account would be to limit the number of accounts that it can use (so that trying to allocate your forging power to a "full" account would actually fail) or to limit the max. amount of forging power to a max. % of total coins (say 1%). Of course there is no reason that both of these limits would not be able to be imposed.

Someone else suggested the leased forging power to be restricted according to the balance of the forging account and I think that it could also be a reasonable way to do it.

The key thing that we are going to want to have is a "lot of small pools" rather then a "few huge ones" so I think we should try and focus on ideas that are going to make it easier for small pools and harder for large pools.

Unfortunately the CoinWitness thing and SCIP "goes right over my head" so I won't be specifying anything like it with our initial AT.

For the case of atomic cross-chain transactions an AT to do the equivalent of the pair of Bitcoin txs required is actually quite straight forward.

It will require a specific Nxt AT API command to "verify that the SHA256" of a value matches what is expected (this will need to be discussed with CfB).

Anyway after you've signed and returned the Bitcoin refund to the person wanting to buy NXT from you then you publish an AT containing the SHA256 hash the buyer sent you and their account # (for sending to if it proceeds) and giving that AT the agreed amount (so the NXT is under the AT's control).

The guy wanting to purchase NXT then sends the "secret key" as an AM to the AT - the AT will verify that the secret in the message is correct (i.e. when hashed gives the matching value) and then sends its balance to the "NXT buyer".

The NXT seller would then have to fix up the raw transaction by inserting the secret into it and broadcasting it (not quite as easy actually compared to the Nxt side of things) although it should be easy enough to "whip up" a script or small program to help with the Bitcoin side of things.

As AT has a "Turing complete" instruction set and state then aside from restrictions to the max. # of steps that can be executed by any "forger" and restrictions to the max. # of bytes of state you will be permitted to use you will be able make an AT do whatever you like it to.

For the initial implementation there will be fairly strict limits on data storage (state). A possible way to be able to have more state will be to use Service Providers for that down the track.

The amount of fee that needed to be paid to register for a start and then also perhaps we could limit Class B Asset to not being able to have as many units/shares.

One idea that comes to mind is perhaps to have different Asset "classes" and price them differently (allowing Assets to be affordable to most but perhaps making A class Assets more expensive to list than B class).

I'd still keep the name to be unique (so no confusion) and a client might simply display A class assets in say a different color to B class ones.

In fact one possibly even better approach would be to add the following rule:

A1 - B
A2 - B

When faced with the above (two branches with the same height and weight) then the "correct" one is the one with the lowest previous account number (so lets say A1 - B wins).

This rule would continue "backwards" if A1 and A2 were the same account number.

Although some parts of the network still might only have seen A2 - B at least there would be no ambiguity for those that have seen both branches (so B's effort to confuse would be far less effective).

Also people who see both branches might decide to "disconnect B" from their list of peers.