I think I know where it was 
https://github.com/kac-/tmp/blob/master/nxt-decompile/Nxt.java
By closed I also mean build environment and libraries - to initially invest in NXT one had to either believe that everything is alright or have access to inner circles.
True, I can be totally wrong about EC, Iām basing only on posts found here.
Haha, funny coincidence.
Nxt is a platform, easily extendable platform. If we can embed everything then why not?[/quote]
Another point about integrating basic stuff like this is: standardization.
If you rely on a platform like Nxt or like Python or like Java, you can either write code yourself, use a third party library OR use the standard/core library.
What would you prefer most? The core libs I guess. The same applies for Nxt. There would be basic things implemented over and over again by somewhere else. Implementation and protocol details are simply personal taste. So, we get over with these and fix them once an for all.
Nxt is a platform, easily extendable platform. If we can embed everything then why not?[/quote]
Another point about integrating basic stuff like this is: standardization.
If you rely on a platform like Nxt or like Python or like Java, you can either write code yourself, use a third party library OR use the standard/core library.
What would you prefer most? The core libs I guess. The same applies for Nxt. There would be basic things implemented over and over again by somewhere else. Implementation and protocol details are simply personal taste. So, we get over with these and fix them once an for all.[/quote]
Thatās why you use BouncyCastle and custom curve [not sayin itās bad] 
Do not know what the one has to do with the other. Defining as standard is not the same as using a standard. Everyone can feel free to use whatever they like.
Most people will use Nxt Exchange, although some might think a custom implementation would fit their needs better.
Same goes for the Nxt Reference Software (NRS). Most people will use that one. Some might needs a Assembler implementation of Nxt.
80% of the use-cases are covered by the standard protocol and implementation. The other 20% will find their own way.
That is what I meant by saying Nxt defines certain standards that most of the time will cover all use-cases. Maybe, some developers would have a nicer and cleaner and fancier solution, but 80% of the developers simply have other things to do and are grateful when the basic building blocks of an economic platform are ready to use.
[quote=ākac-, post:10, topic:2442ā]
That is the idea. They are forced to do what is good for the cluster aka the global economy. As far as I know there is only one global economy now.
I think I now understand what you mean:
EC does not cement mechanism as such. It could be seen as a mechanism to deliberately destabilize Nxt and make it obvious when people behave badly. So, this is the component that forces human cooperation that is needed to recreate the stability.
Do not know what the one has to do with the other. Defining as standard is not the same as using a standard. Everyone can feel free to use whatever they like.
Most people will use Nxt Exchange, although some might think a custom implementation would fit their needs better.
Same goes for the Nxt Reference Software (NRS). Most people will use that one. Some might needs a Assembler implementation of Nxt.
80% of the use-cases are covered by the standard protocol and implementation. The other 20% will find their own way.
That is what I meant by saying Nxt defines certain standards that most of the time will cover all use-cases. Maybe, some developers would have a nicer and cleaner and fancier solution, but 80% of the developers simply have other things to do and are grateful when the basic building blocks of an economic platform are ready to use.[/quote]
I was just teasing about preferences 
What I like in Nxt, and what gives you huge advantage, is Java usage- you donāt have to worry about memory safety, itās easier/faster to build and test ā easier/faster to extend and bring new features basing on market needs. It also brings some disadvantages like FUD on Java vulnerabilities(largely overstated imo) or Oracle dependence(thatās more serious, idk whatās their JVM market coverage, 90%?).
It will be more convenient to implement some DoS resistant services directly in protocol for sure, the key is to make it safe - at the end of the day itās not about fancy features but users money and their trust.
And thatās why I love PPC, few megabytes of ~bare metal financial tool, update release schedule longer than whole lifetime of some $M coins, conservative development- I trust it. Start daemon and forget(yup, we have problems with users not updating their clients 
). Itās harder to sell such coin on current market but Iām sure that demand for it will grow with market maturation.
Does Peercoin suffer from the Nothing at Stake problem? As far as I can recall it does not.
Does Peercoin suffer from the Nothing at Stake problem? As far as I can recall it does not.[/quote]
For those who think itās a problem, Peercoin does. I have never seen an analysis showing that a āNothing at Stakeā attack to be profitable, so I am not sure it is actually a problem.
There is no such problem as N@S - http://www.reddit.com/r/peercoin/comments/1sokg2/proof_of_stake_and_peercoins_historic_significance/ce17qci[/quote]
Good links!
Thanks for helping putting this thread to rest.
Any news? Ideas? Reviews for EC?