Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: ImmortAlex on January 03, 2014, 01:01:42 PM



Title: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:01:42 PM
While lurking for injected bugs, I found that some parts of Nxt code makes my eyes bleed. With hope that I have enough programming skills (probably better, than my runglish :) ), I'm starting this thread. Not for bounty, but for better quality (but donations welcome, as usual :) ).

First of all, thanks to IntelliJ IDEA code analysis, I see a lot of syncronized with potentially wrong usage.
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
While in some places such usage may be safe, I think it's very bad practice anyway.

More to come...


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 03, 2014, 01:04:48 PM
Watching


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:14:05 PM
Small suggestion on usage of Collection.toArray().
I see a lot of calls like
Code:
peers.toArray(new Peer[0])
1. It is completely useless and equal to simple toArray() call.
2. It is better in terms of speed and memory usage to code like this:
Code:
peers.toArray(new Peer[peers.size()])


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:22:21 PM
One more thanks to IDEA: line 6533, peer can be null. At least there's check for null above and below, but not here.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:26:42 PM
One more thanks to IDEA: line 6533, peer can be null. At least there's check for null above and below, but not here.
Relax, I am also using IntelliJ. And the above has been fixed in 0.4.9e.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 03, 2014, 01:26:54 PM
One more thanks to IDEA: line 6533, peer can be null. At least there's check for null above and below, but not here.

Hey, who is checking the code, u or robot?  ;D


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:33:49 PM
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
In 0.4.9e, they are. :-)
Quote
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
I have fixed, I hope, the synchronization issues related to Blocks and Transactions in 0.4.9e. The synchronization in Accounts is on my TODO list for the next version.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:37:00 PM
Okey, let me rewrite something :)

Code:
        static Peer getAnyPeer(int state, boolean applyPullThreshold) {

            synchronized (peers) {

                Collection<Peer> peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
                Iterator<Peer> iterator = peers.iterator();
                while (iterator.hasNext()) {

                    Peer peer = iterator.next();
                    if (peer.blacklistingTime > 0 || peer.state != state || peer.announcedAddress.length() == 0 || (applyPullThreshold && enableHallmarkProtection && peer.getWeight() < pullThreshold)) {

                        iterator.remove();

                    }

                }

                if (peers.size() > 0) {

                    Peer[] selectedPeers = peers.toArray(new Peer[0]);
...

For memory usage I prefer to code like this:

Code:
                List<Peer> selectedPeers = new ArrayList<>();
                for (Map.Entry<String, Peer> entry : peers.entrySet()) {
                    Peer peer = entry.getValue();
                    if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() != 0 && ((!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold))) {
                        selectedPeers.add(peer);
                    }
                }

And even more, List selectedPeers can be reused, if used only in this method.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:38:15 PM
Relax, I am also using IntelliJ. And the above has been fixed in 0.4.9e.

I have fixed, I hope, the synchronization issues related to Blocks and Transactions in 0.4.9e. The synchronization in Accounts is on my TODO list for the next version.

Good news!
Okey, let me find something really interesting...


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:38:44 PM
Small suggestion on usage of Collection.toArray().
I see a lot of calls like
Code:
peers.toArray(new Peer[0])
1. It is completely useless and equal to simple toArray() call.
2. It is better in terms of speed and memory usage to code like this:
Code:
peers.toArray(new Peer[peers.size()])
A search for toArray in 0.4.9e finds only two instances in old, commented out code. Keep digging, I am still a step ahead. :)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 03, 2014, 01:39:58 PM
Okey, let me rewrite something :)

Code:
        static Peer getAnyPeer(int state, boolean applyPullThreshold) {

            synchronized (peers) {

                Collection<Peer> peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
                Iterator<Peer> iterator = peers.iterator();
                while (iterator.hasNext()) {

                    Peer peer = iterator.next();
                    if (peer.blacklistingTime > 0 || peer.state != state || peer.announcedAddress.length() == 0 || (applyPullThreshold && enableHallmarkProtection && peer.getWeight() < pullThreshold)) {

                        iterator.remove();

                    }

                }

                if (peers.size() > 0) {

                    Peer[] selectedPeers = peers.toArray(new Peer[0]);
...

For memory usage I prefer to code like this:

Code:
                List<Peer> selectedPeers = new ArrayList<>();
                for (Map.Entry<String, Peer> entry : peers.entrySet()) {
                    Peer peer = entry.getValue();
                    if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() != 0 && ((!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold))) {
                        selectedPeers.add(peer);
                    }
                }

And even more, List selectedPeers can be reused, if used only in this method.

This proves u r not BCNext. Ur and his logic r completely different!

(Or u did this intentionally :))


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:42:34 PM
Keep digging, I am still a step ahead. :)
Two step ahead (0.4.8 and 0.4.9), and I hope you start to do third step already :)


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:43:43 PM
Okey, let me rewrite something :)

For memory usage I prefer to code like this:

Code:
                List<Peer> selectedPeers = new ArrayList<>();
                for (Map.Entry<String, Peer> entry : peers.entrySet()) {
                    Peer peer = entry.getValue();
                    if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() != 0 && ((!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold))) {
                        selectedPeers.add(peer);
                    }
                }

And even more, List selectedPeers can be reused, if used only in this method.
You are reading my mind. My tinfoil hat has been leaking!
My replacement of the same lines in getAnyPeer, already in 0.4.9e:
Code:
            List<Peer> selectedPeers = new ArrayList<Peer>();

            for (Peer peer : Nxt.peers.values()) {

                if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() > 0
                        && (!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold)) {

                    selectedPeers.add(peer);

                }

            }



Title: Re: Nxt source code analysis (QA)
Post by: bitcoinpaul on January 03, 2014, 01:44:27 PM
You little nerds.  :-*


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:44:49 PM
This proves u r not BCNext. Ur and his logic r completely different!
I am from generation "640k is enough" :) So I dislike such memory copies.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:47:19 PM
My replacement of the same lines in getAnyPeer, already in 0.4.9e:
Code:
            List<Peer> selectedPeers = new ArrayList<Peer>();

            for (Peer peer : Nxt.peers.values()) {

                if (peer.blacklistingTime <= 0 && peer.state == state && peer.announcedAddress.length() > 0
                        && (!applyPullThreshold || !enableHallmarkProtection || peer.getWeight() >= pullThreshold)) {

                    selectedPeers.add(peer);

                }

            }

AFAIR, HashMap.values() make a copy, while HashMap.entrySet() definitely not.
So my variant is even better. You sync in peers anyway, so it is safe.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:49:14 PM
I hope you already remove "double copy"
Code:
peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
from thread, which is start every second :)


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 03, 2014, 01:50:37 PM
There are also a lot of places where the base Exception is being caught and suppressed. It's generally best to only catch exceptions that you can handle, otherwise, you're just continuing without knowing what went wrong and your code could be in a bad state.

Two examples:
(1) Around all the parseInts where you're loading config, you should be catching the more specific NumberFormatException (which you can handle) than Exception (which you probably can't).
(2) It does seem odd that if saveTransactions fails by throwing an exception (which it can) the code just ignores it and keeps going. I would expect it to do something in that case.

I'm unsure what you're seeding transactions.nxt with when it's not found? Are those the genesis block transactions? Shouldn't they be getting downloaded from somewhere?

It's kind of awkward to have a private class (e.g. Blocks) populate a member of the containing type directly (e.g. Blocks.loadBlocks assigns Nxt.blocks directly). It looks like you're using classes primarily for namespacing (e.g. grouping related functions) instead of creating standalone classes. For example, the Blocks class cannot be used anywhere else because it has hard dependencies on Nxt (which is also doing server stuff). Might not be a big deal in your case, but it's usually better to minimize class dependencies by creating small, reusable classes with a single purpose (in other words, following the SOLID principle).

The file handles on error conditions:

Code:
		static void loadBlocks(String fileName) throws Exception {

FileInputStream fileInputStream = new FileInputStream(fileName);
ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream);
blockCounter = objectInputStream.readInt();
blocks = (HashMap<Long, Block>)objectInputStream.readObject();
lastBlock = objectInputStream.readLong();
objectInputStream.close();
fileInputStream.close();

If read object throws here, neither stream will be closed. You should consider moving the closes to a finally block.

That's all I have for now, but I'll probably look the code more later :).
         
      }


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:52:02 PM
AFAIR, HashMap.values() make a copy, while HashMap.entrySet() definitely not.
So my variant is even better. You sync in peers anyway, so it is safe.
I didn't know that, are you sure? From the java source of ConcurrentHashMap, which Nxt.peers already is in 0.4.9e:
Code:
    /**
     * Returns a {@link Collection} view of the values contained in this map.
     * The collection is backed by the map, so changes to the map are
     * reflected in the collection, and vice-versa.  The collection
     * supports element removal, which removes the corresponding
     * mapping from this map, via the <tt>Iterator.remove</tt>,
     * <tt>Collection.remove</tt>, <tt>removeAll</tt>,
     * <tt>retainAll</tt>, and <tt>clear</tt> operations.  It does not
     * support the <tt>add</tt> or <tt>addAll</tt> operations.
     *
     * <p>The view's <tt>iterator</tt> is a "weakly consistent" iterator
     * that will never throw {@link ConcurrentModificationException},
     * and guarantees to traverse elements as they existed upon
     * construction of the iterator, and may (but is not guaranteed to)
     * reflect any modifications subsequent to construction.
     */
    public Collection<V> values() {
        Collection<V> vs = values;
        return (vs != null) ? vs : (values = new Values());
    }


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:53:15 PM
Just make sure you don't give him/them the whole 0.4.9e code in this topic!   ;)
I have no time to be full-time Nxt core developer :(


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 01:53:27 PM
I hope you already remove "double copy"
Code:
peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
from thread, which is start every second :)
Yes. There is no invocation of clone() in 0.4.9e.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 01:58:52 PM
I didn't know that, are you sure? From the java source of ConcurrentHashMap, which Nxt.peers already is in 0.4.9e:
You are right, values backed by the map.
Hmm, I remember the times when values() return copy of map. Or my memory is very bad...


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 02:02:13 PM
There are also a lot of places where the base Exception is being caught and suppressed. It's generally best to only catch exceptions that you can handle, otherwise, you're just continuing without knowing what went wrong and your code could be in a bad state.
Absolutely agree, haven't had the time to fix in 0.4.9e.
Quote
I'm unsure what you're seeding transactions.nxt with when it's not found? Are those the genesis block transactions? Shouldn't they be getting downloaded from somewhere?
Those are the genesis block transactions, hardcoded in the code. My account number is somewhere there too... ;)
Quote
It's kind of awkward to have a private class (e.g. Blocks) populate a member of the containing type directly (e.g. Blocks.loadBlocks assigns Nxt.blocks directly). It looks like you're using classes primarily for namespacing (e.g. grouping related functions) instead of creating standalone classes. For example, the Blocks class cannot be used anywhere else because it has hard dependencies on Nxt (which is also doing server stuff). Might not be a big deal in your case, but it's usually better to minimize class dependencies by creating small, reusable classes with a single purpose (in other words, following the SOLID principle).
Agree. The code doesn't exactly follow any textbook design patterns either. :) Significant refactoring is needed, but no time for it now, need to fix the critical bugs first.
Quote
If read object throws here, neither stream will be closed. You should consider moving the closes to a finally block.
Rest assured, all streams are safely closed in finally blocks (or actually using java 7 try-with-resources) in 0.4.9e.


Title: Re: Nxt source code analysis (QA)
Post by: NxtChg on January 03, 2014, 02:12:10 PM
Hire this guy. If only for his nick :)


Title: Re: Nxt source code analysis (QA)
Post by: mcjavar on January 03, 2014, 02:26:49 PM
Hire this guy. If only for his nick :)

yes, do it asap! :)


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 03, 2014, 02:29:53 PM
Found
Code:
static byte[] convert(String string)
and
Code:
static String convert(byte[] bytes)
ineffictive.
Need I suggest some solutions (like Apache Commons :) )?

Edit: nevermind. I'm too strict this evening...


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 02:42:14 PM
Found
Code:
static byte[] convert(String string)
and
Code:
static String convert(byte[] bytes)
ineffictive.
Need I suggest some solutions (like Apache Commons :) )?
Those convert methods also bothered me at first look, but I decided to leave it for later if they need optimizing. My girlfriend promised to buy me a license for YourKit (hey, they have a sale now, personal license is only $99 instead of $500) and I will spend some time profiling. It is only worth optimizing things that really are measured to be a problem.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 03, 2014, 03:09:27 PM
Hire this guy. If only for his nick :)

yes, do it asap! :)
Well, he just mentioned a few posts above that he is too busy to be a full time developer. But if ImmortAlex wants to contribute part time, we seem to think similarly so this may work.

The problem right now is it will be difficult to split the work between multiple developers, as you can see everything is in one huge file which needs a lot of refactoring. Distributing who can do what without stepping on each others work, and then merging the changes, will take almost the same time as one person doing it all.


Title: Re: Nxt source code analysis (QA)
Post by: mcjavar on January 03, 2014, 03:18:31 PM
Hire this guy. If only for his nick :)

yes, do it asap! :)
Well, he just mentioned a few posts above that he is too busy to be a full time developer. But if ImmortAlex wants to contribute part time, we seem to think similarly so this may work.

The problem right now is it will be difficult to split the work between multiple developers, as you can see everything is in one huge file which needs a lot of refactoring. Distributing who can do what without stepping on each others work, and then merging the changes, will take almost the same time as one person doing it all.


So you plan to split it in different files? I am not an expert, but did some java before. When I saw that there is only one file I was shocked, to be honest...


Title: Re: Nxt source code analysis (QA)
Post by: NxtChg on January 03, 2014, 03:19:18 PM
The problem right now is it will be difficult to split the work between multiple developers, as you can see everything is in one huge file which needs a lot of refactoring. Distributing who can do what without stepping on each others work, and then merging the changes, will take almost the same time as one person doing it all.

Hey, you see he's good at proofreading :)

That could be a code review, which is never a bad thing. And Alex would have occasional pocket money on the side :)


Title: Re: Nxt source code analysis (QA)
Post by: bitcool on January 03, 2014, 07:55:28 PM
watching,  statically  ;D


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 03, 2014, 07:59:25 PM
While lurking for injected bugs, I found that some parts of Nxt code makes my eyes bleed. With hope that I have enough programming skills (probably better, than my runglish :) ), I'm starting this thread. Not for bounty, but for better quality (but donations welcome, as usual :) ).

First of all, thanks to IntelliJ IDEA code analysis, I see a lot of syncronized with potentially wrong usage.
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
While in some places such usage may be safe, I think it's very bad practice anyway.

More to come...

The author did not even bother to run the code through static code analysis.

Also,  where the hell are the JUnit tests?


How can anyone expect this kind of code to be used to handle their currency?


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 03, 2014, 08:02:18 PM
Found
Code:
static byte[] convert(String string)
and
Code:
static String convert(byte[] bytes)
ineffictive.
Need I suggest some solutions (like Apache Commons :) )?

Edit: nevermind. I'm too strict this evening...

I don't think this developer has even heard of Apache commons.

I mean, it is obvious that he doesn't even know how to use a java package.


Title: Re: Nxt source code analysis (QA)
Post by: Revelations86 on January 03, 2014, 08:18:25 PM
For us common folks, what does this mean in plan english?  ;D


Title: Re: Nxt source code analysis (QA)
Post by: GröBkAz on January 03, 2014, 08:25:11 PM
While lurking for injected bugs, I found that some parts of Nxt code makes my eyes bleed. With hope that I have enough programming skills (probably better, than my runglish :) ), I'm starting this thread. Not for bounty, but for better quality (but donations welcome, as usual :) ).

First of all, thanks to IntelliJ IDEA code analysis, I see a lot of syncronized with potentially wrong usage.
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
While in some places such usage may be safe, I think it's very bad practice anyway.

More to come...

The author did not even bother to run the code through static code analysis.

Also,  where the hell are the JUnit tests?


How can anyone expect this kind of code to be used to handle their currency?

I do not think that this should be taken here as an opportunity to insult the developer. Please, show more humility for the work of others, even if you dont like the project.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 03, 2014, 08:29:01 PM
While lurking for injected bugs, I found that some parts of Nxt code makes my eyes bleed. With hope that I have enough programming skills (probably better, than my runglish :) ), I'm starting this thread. Not for bounty, but for better quality (but donations welcome, as usual :) ).

First of all, thanks to IntelliJ IDEA code analysis, I see a lot of syncronized with potentially wrong usage.
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
While in some places such usage may be safe, I think it's very bad practice anyway.

More to come...

The author did not even bother to run the code through static code analysis.

Also,  where the hell are the JUnit tests?


How can anyone expect this kind of code to be used to handle their currency?

I do not think that this should be taken here as an opportunity to insult the developer. Please, show more humility for the work of others, even if you dont like the project.


This code is supposed to secure the currency that people own,   so I expect top notch software development best practices, not work that looks like it came out of a high school coding project.

I am teling you like it is,  if you can't handle the truth then so be it.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 03, 2014, 08:31:17 PM
For us common folks, what does this mean in plan english?  ;D

in plain english... the code has not been tested exhaustively.

So its like flying an airplane that hasn't been tested to fly.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 03, 2014, 08:34:57 PM
I hope you already remove "double copy"
Code:
peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
from thread, which is start every second :)

Which is dumb as hell because concurrent collections handles this kind of stuff.

So why is this poorly designed code out in the wild securing a currency?

It is only a matter of time before some guy drains out all the money out of all accounts.

This is a ticking time bomb!

Don't tell me I did not warn you folks.


Title: Re: Nxt source code analysis (QA)
Post by: theKnownUnknown on January 03, 2014, 09:02:08 PM
Now we know why this source code was not published before. This is a ticking time bomb. If you try to refactor this, it will explode. Do not take it personally  :). Just my opininion and experience.


Title: Re: Nxt source code analysis (QA)
Post by: NXT on January 03, 2014, 10:09:35 PM
While lurking for injected bugs, I found that some parts of Nxt code makes my eyes bleed. With hope that I have enough programming skills (probably better, than my runglish :) ), I'm starting this thread. Not for bounty, but for better quality (but donations welcome, as usual :) ).

First of all, thanks to IntelliJ IDEA code analysis, I see a lot of syncronized with potentially wrong usage.
Static variables like peers, blocks, accounts, users are not final. They are initialized at start, so it is not a big flaw right now, but who knows about future.
When I look more deeply in syncronizations, I see a lot of places, where author get content of such global collection and then sync on it, but not sync on collection itself. Example:
Code:
Block.analyse() method:

Account generatorAccount = accounts.get(Account.getId(generatorPublicKey));
synchronized (generatorAccount) {
    generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
    generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);
}
While in some places such usage may be safe, I think it's very bad practice anyway.

More to come...

The author did not even bother to run the code through static code analysis.

Also,  where the hell are the JUnit tests?


How can anyone expect this kind of code to be used to handle their currency?

I do not think that this should be taken here as an opportunity to insult the developer. Please, show more humility for the work of others, even if you dont like the project.


This code is supposed to secure the currency that people own,   so I expect top notch software development best practices, not work that looks like it came out of a high school coding project.

I am teling you like it is,  if you can't handle the truth then so be it.


hey mister big mouth, if its not safe break it right now or stfu


Title: Re: Nxt source code analysis (QA)
Post by: NXT on January 03, 2014, 10:19:31 PM
Found
Code:
static byte[] convert(String string)
and
Code:
static String convert(byte[] bytes)
ineffictive.
Need I suggest some solutions (like Apache Commons :) )?

Edit: nevermind. I'm too strict this evening...

I don't think this developer has even heard of Apache commons.

I mean, it is obvious that he doesn't even know how to use a java package.


 :D :D :D :D ;D ;D mister ixcoin alternative for bitcoin roflmao

iXcoin - The First Alternative to Bitcoin.

Been around since 2011, price has been going up since 2012.

Extremely secure,  hash rate about 1/4th of Bitcoin.

Read the statistics page here:  www.ixcoin.co


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 03, 2014, 11:22:26 PM
Code:
Here are a few more thoughts:

(1) This is a minor thing, but i don't think you're checking for overflow in any of the request parameters:
[code]
int timestamp = ((Long)transactionData.get("timestamp")).intValue();
short deadline = ((Long)transactionData.get("deadline")).shortValue();
byte[] senderPublicKey = convert((String)transactionData.get("senderPublicKey"));
long recipient = (new BigInteger((String)transactionData.get("recipient"))).longValue();
int amount = ((Long)transactionData.get("amount")).intValue();

You're casting the value to a Long and then to an integer, but not checking if truncation occurred. [I would probably move the validation to the Transaction or a transaction factory function. You can also move the validation of positive and valid amounts and fees here].

(2) You're locking around every call to setBalance / setUnconfirmedBalance, which makes it easy to call the functions incorrectly if you forget to call them from within a lock. IMO, it would make sense to move some of that locking into the functions themselves so they can't be called incorrectly. [you can also change these functions to incrementXyz, since that's what you appear to be doing.

(3) Instead of a giant doGet function, imo, it would make sense to consider a chain of responsibility where you move each potential action into a separate object, e.g. :
Code:
interface GetHandler
{
    bool canHandle(string requestType);
    void handle(response, request);
}
};
[/code]


Title: Re: Nxt source code analysis (QA)
Post by: pinarello on January 04, 2014, 12:14:50 AM
I hope you already remove "double copy"
Code:
peers = ((HashMap<String, Peer>)Nxt.peers.clone()).values();
from thread, which is start every second :)

Which is dumb as hell because concurrent collections handles this kind of stuff.

So why is this poorly designed code out in the wild securing a currency?

It is only a matter of time before some guy drains out all the money out of all accounts.

This is a ticking time bomb!

Don't tell me I did not warn you folks.

Always going to be a trade off between high liquidity and high growth.

I own BTC (30%) ... high liquidity, can easily go on margin, can trade futures.  most flexible trading vehicle out there.
I own LTC (20%) high liquidity only in BTC-E, however potential BTCChina and mtgox listing.
I own NMC (40%) decent liquidity, normally follows BTC, but higher potential because of low valuation.  2nd highest hash rate among coins, however needs more aggressive dev support. I like it because not a lot of folks have big holdings here.

and for my purely speculative play ... don't day trade this coin... liquidity isn't great at the moment.
I own IXC (10%)

Anyway, do be careful with a lot of the "pump and dump" coins.   You know, the ones with a high mint rate and with hundreds of millions of coins.


busted, your agenda is clear... can't get over the NXT alias system is it?


dont get emotional when trading, you don't have to do this you know ;)

Pin


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 04, 2014, 12:51:55 AM

Always going to be a trade off between high liquidity and high growth.

I own BTC (30%) ... high liquidity, can easily go on margin, can trade futures.  most flexible trading vehicle out there.
I own LTC (20%) high liquidity only in BTC-E, however potential BTCChina and mtgox listing.
I own NMC (40%) decent liquidity, normally follows BTC, but higher potential because of low valuation.  2nd highest hash rate among coins, however needs more aggressive dev support. I like it because not a lot of folks have big holdings here.

and for my purely speculative play ... don't day trade this coin... liquidity isn't great at the moment.
I own IXC (10%)

Anyway, do be careful with a lot of the "pump and dump" coins.   You know, the ones with a high mint rate and with hundreds of millions of coins.


busted, your agenda is clear... can't get over the NXT alias system is it?


dont get emotional when trading, you don't have to do this you know ;)

Pin


My agenda is clear?   By having a very conservative crypto-currency portfolio?

My only agenda is in the case of NXT is to figure out if it is legit or not.  So far,  I am very unimpressed.

Every investor should do their due diligence, I am doing mine.  So far, it hasn't passed the sniff test.

I'm sorry if my standards are much higher than most NXT investors.



Title: Re: Nxt source code analysis (QA)
Post by: newsilike on January 04, 2014, 01:06:52 AM

Always going to be a trade off between high liquidity and high growth.

I own BTC (30%) ... high liquidity, can easily go on margin, can trade futures.  most flexible trading vehicle out there.
I own LTC (20%) high liquidity only in BTC-E, however potential BTCChina and mtgox listing.
I own NMC (40%) decent liquidity, normally follows BTC, but higher potential because of low valuation.  2nd highest hash rate among coins, however needs more aggressive dev support. I like it because not a lot of folks have big holdings here.

and for my purely speculative play ... don't day trade this coin... liquidity isn't great at the moment.
I own IXC (10%)

Anyway, do be careful with a lot of the "pump and dump" coins.   You know, the ones with a high mint rate and with hundreds of millions of coins.


busted, your agenda is clear... can't get over the NXT alias system is it?


dont get emotional when trading, you don't have to do this you know ;)

Pin


My agenda is clear?   By having a very conservative crypto-currency portfolio?

My only agenda is in the case of NXT is to figure out if it is legit or not.  So far,  I am very unimpressed.

Every investor should do their due diligence, I am doing mine.  So far, it hasn't passed the sniff test.

I'm sorry if my standards are much higher than most NXT investors.

Then you might consider joining in later if your standards cant be matched yet. The pricle level will grow accordingly tho  :(


Title: Re: Nxt source code analysis (QA)
Post by: EvilDave on January 04, 2014, 01:11:31 AM
For us common folks, what does this mean in plan english?  ;D

in plain english... the code has not been tested exhaustively.

So its like flying an airplane that hasn't been tested to fly.

That coders/devs are like cats...one on it's own is fine, but the chances of a massive fight increase exponentially with the number of coders (or cats) in the same space.

Is it possible for a coder to look at someone elses code and not start criticizing?

Keep it up, guys,  u're doing good work, even the trolls are useful to provide some extra motivation.



Title: Re: Nxt source code analysis (QA)
Post by: NxtChoice on January 04, 2014, 04:06:36 AM

Watching.

I care much more about the core of Nxt than the code style. We can think that BCNext may be not a great Java programmer(maybe he intended to use Java instead of C++ just for some reasons), but he is a great guy who invented Nxt, especially the thought, theory of Nxt. If the theory works ok and it is secure in theory, all of you guys can implement it in a reliable time frame and get better efficiency of the code. Of course, I want to thank all you guys taking time to advance the project.



Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 04:27:42 AM
Being good Android device, I need to have deep sleep at night. Now I woke up and continue to read the code.

Note to those who complain about one big file or JUnit absence. This is very young project. There're different approaches to start project. You can write a lot of tests, interfaces, abstract implementations... and have no working code for years (I personally have such expirience). Or you can write quick and dirty, and have something to show to your customers since the beginning. Both approach have its good and bad sides.

If you want - you can start rewrite Nxt right now. You can even fork it. With blackjack and hookers. There are just 6800 lines of code, and a lot of that lines are just empty :)


Title: Re: Nxt source code analysis (QA)
Post by: User705 on January 04, 2014, 04:36:25 AM
Forking with hookers.  I'm sure there's a GIF somewhere on the net that would be appropriate but I'm lazy.


Title: Re: Nxt source code analysis (QA)
Post by: bitcool on January 04, 2014, 04:51:51 AM
Now we know why this source code was not published before. This is a ticking time bomb. If you try to refactor this, it will explode. Do not take it personally  :). Just my opininion and experience.

You have to give the creator credit for implementing the first version bitcoin-era crytocurrency in Java. I am sure a lot of time and effort were invested in this.

From a brief glance of it, it's definitely a very interesting and unorthodox way using JEE, and Java in general:

1) Application running as one HUGE servlet
2) One file, one class, many inner classes
3) All (almost) static methods
4) No test harness
...

With only 6800 lines of code, it's amazing this thing actually works!  It just shows how powerful java libraries are.  but.... the more layers you have (JVM, Jetty, 3rd party Jars), the more vulnerable it becomes to security threats.

It's probably fine (and fun) for a play project, but for a currency? I agree, I think I hear the ticking sound.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 04, 2014, 05:03:26 AM
Being good Android device, I need to have deep sleep at night. Now I woke up and continue to read the code.

Note to those who complain about one big file or JUnit absence. This is very young project. There're different approaches to start project. You can write a lot of tests, interfaces, abstract implementations... and have no working code for years (I personally have such expirience). Or you can write quick and dirty, and have something to show to your customers since the beginning. Both approach have its good and bad sides.

If you want - you can start rewrite Nxt right now. You can even fork it. With blackjack and hookers. There are just 6800 lines of code, and a lot of that lines are just empty :)

I am still trying to get to the gist of this implementation.

Nobody can seem to give me some straight answers on how exactly it should work.

Well that 6800 lines of code also has some embedded elliptic cryptographic stuff, so the actual real code is even less.   


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 05:48:20 AM
What is interesting for me... It appears that even if some transaction with big fee doesn't fit to block because block is almost full, some cheaper transaction can be put to block if it is very small. I always thought that deadline is only fee-based, and cheaper transactions always need to wait next block.
It's not a bug, it's a feature ;)


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 06:02:58 AM
Seems like Peer.getAnyPeer() can return even non-halmarked peer in rare case?
Is it ok? What is the reason?


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 04, 2014, 06:53:25 AM
Seems like Peer.getAnyPeer() can return even non-halmarked peer in rare case?
Is it ok? What is the reason?

The reason is to give non-hallmarked peers to take part in the show.


Title: Re: Nxt source code analysis (QA)
Post by: gsan1 on January 04, 2014, 09:35:46 AM
Doing some black box tests right now. The code compiles & starts fine, so at a first glance there seems to be no flaw concerning the init()/destroy() or account unlocking/locking.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 12:34:16 PM
Nice check in Block.verifyBlockSignature()

Code:
Account account = accounts.get(Account.getId(generatorPublicKey));

....

if (!Arrays.equals(generatorPublicKey, account.publicKey)) {
    return false;
}

Seems like inside this check must be big red banner: "Now we need to use full 256 hash for account ID" :)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 04, 2014, 12:52:13 PM
Nice check in Block.verifyBlockSignature()

Code:
Account account = accounts.get(Account.getId(generatorPublicKey));

....

if (!Arrays.equals(generatorPublicKey, account.publicKey)) {
    return false;
}

Seems like inside this check must be big red banner: "Now we need to use full 256 hash for account ID" :)

Why?


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 01:11:34 PM
You get account ID from pubkey of block generator, get Account by this ID, then compare account pubkey with generator's one, and they didn't match. I think it's because of ID collision: two different pubkeys gives the same ID.
Account ID is SHA-256 hash of pubkey, but currently only 8 last bytes of hash is used. AFAIR there were talks about such collisions, and the conclusion was to use more bytes of hash only when we start to get collisions.
Am I miss something?

(It's not a talk about bug, I'm just try to understand code)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 04, 2014, 01:19:54 PM
You get account ID from pubkey of block generator, get Account by this ID, then compare account pubkey with generator's one, and they didn't match. I think it's because of ID collision: two different pubkeys gives the same ID.
Account ID is SHA-256 hash of pubkey, but currently only 8 last bytes of hash is used. AFAIR there were talks about such collisions, and the conclusion was to use more bytes of hash only when we start to get collisions.
Am I miss something?

(It's not a talk about bug, I'm just try to understand code)

It's a feature.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 03:25:31 PM
Second day of code reading. Somewhere in the middle of the file :) So some new thoughts.

The problem is not a 6800 lines itself...
I don't like that code is not object-oriented well. It's more like plain C with structures. Direct access to variables, some small code dublications here and there, you know... Sometimes it's hard to track code and data flow. I hope at the end of reading I will find some global flaws :) but locally, inside small methods and code branches everything looks good. Doesn't check that curve math actually :) Hope it has no flaws.


Now I clearly see how they keep coins :) And I don't like it too.
For those who didn't know: transactions keep amount and fee in signed 32-bit integers. 1 billion max, no fractional part at all. Blocks keep total amount and total fee the same way. It need to be changed if we want to have 0.01 fee. And this is base part of internal data structures.
Account keep it's balance in 64-bit signed integer. And that value is 100 times greater than amount and fee in transaction. So there's room to have 0.01 precision (fixed-point math, you know).
Right now everytime when there's addition or substraction from account balance to transaction we need to multiply or divide by 100. Every time. Not in get/set methods, but in code directly. Shit, I'm afraid of this code.
This part must be:
1. Synced with each other. Type of variables for account, transaction and block must be the same.
2. Wrapped to some code which have a deal with that fixed math. If we want 0.0001 precision in future we must change only one place in code.

I hope Jean-Luc make refactorings already :)


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 04, 2014, 04:08:43 PM
One more thought about memory usage.
I see a lot of getBytes().length calls on Transaction and Block. Especially in Transaction.compareTo() this can create a lot of temporaty byte arrays in short time. But length can be easily and much faster calculated without creating array. I think, even for any Attachment.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 04, 2014, 06:19:48 PM
Here are a few more thoughts:

(1) This is a minor thing, but i don't think you're checking for overflow in any of the request parameters:
Code:
			int timestamp = ((Long)transactionData.get("timestamp")).intValue();
short deadline = ((Long)transactionData.get("deadline")).shortValue();
byte[] senderPublicKey = convert((String)transactionData.get("senderPublicKey"));
long recipient = (new BigInteger((String)transactionData.get("recipient"))).longValue();
int amount = ((Long)transactionData.get("amount")).intValue();

You're casting the value to a Long and then to an integer, but not checking if truncation occurred. [I would probably move the validation to the Transaction or a transaction factory function. You can also move the validation of positive and valid amounts and fees here].
I have added a few more checks for the values of Transaction.amount and Transaction.fee in 0.5.0. I agree the validation checks are all over the place and need to be cleaned up.
Quote
(2) You're locking around every call to setBalance / setUnconfirmedBalance, which makes it easy to call the functions incorrectly if you forget to call them from within a lock. IMO, it would make sense to move some of that locking into the functions themselves so they can't be called incorrectly. [you can also change these functions to incrementXyz, since that's what you appear to be doing.
This was already on my list of things to fix, and I have fixed in in 0.5.0, but thanks for noticing.

Quote
(3) Instead of a giant doGet function, imo, it would make sense to consider a chain of responsibility where you move each potential action into a separate object
I know, just no time to do that yet.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 04, 2014, 06:21:51 PM
One more thought about memory usage.
I see a lot of getBytes().length calls on Transaction and Block. Especially in Transaction.compareTo() this can create a lot of temporaty byte arrays in short time. But length can be easily and much faster calculated without creating array. I think, even for any Attachment.
Not fixed yet, but already I have a //TODO: cache? on top of those getBytes() methods. And indeed need to do it for caching the length.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 05, 2014, 04:47:52 AM
Okey, let's talk about one more TODO in you list :)
The blocks, transactions and accounts cache, and how much it will cost to kill our RPi nodes.

As we know since the beginning, blocks.nxt and transactions.nxt is just a result of standard ObjectInputStream work.
At startup they are fully loaded to memory and are there till the end.
So, NRS keeps full blockchain in memory all the time.

Let's do rough calculations. Class Block:
Code:
        int version;
        int timestamp;
        long previousBlock;
        int numberOfTransactions;
        int totalAmount, totalFee;
        int payloadLength;
        byte[] payloadHash;
        byte[] generatorPublicKey;
        byte[] generationSignature;
        byte[] blockSignature;
        byte[] previousBlockHash;
        int index;
        long[] transactions;
        long baseTarget;
        int height;
        long nextBlock;
        BigInteger cumulativeDifficulty;
This is from 0.5.0 actually (sorry for decompilation), but there's almost no difference with 0.4.7.
With 32-bit pointers and no alignment this gives us about 320 bytes for block without transactions, plus 8 byte for each transaction. 64-bit JRE with memory alignment can easily expand this to ~400 bytes. I can't tell you exact numbers, because it heavily depends on JRE implementation, operating system and so on.
Right now we have about 33000 block, which occupies about 11Mb of memory. I think, I should speak "at least 11Mb". Without accounting of long[] transactions...

Okey, take a look at class Transaction:
Code:
        byte type, subtype;
        int timestamp;
        short deadline;
        byte[] senderPublicKey;
        long recipient;
        int amount, fee;
        long referencedTransaction;
        byte[] signature;
        Attachment attachment;

        int index;
        long block;
        int height;
156 bytes without attachement (f.e. alias). Up to 200 in real world. 65000 transactions for now. More than 10Mb of memory. Plus 65000*8 = 0.5Mb of links from blocks to transactions (or we can assume that size of transaction is 164 bytes).

Actual things is even worse because blocks and transactions is not linear lists, but hash maps.
Actual things can be better, because of generatorPublicKey and senderPublicKey can be shared between blocks, transactions and accounts.

I'm bit tired and don't want to calculate size of accounts - it's too small comparing to blocks and transactions.

Next step is to calculate cost of attack.
Attacker can send 255 transactions in block. Let's use simple ordinary payment, 1 NXT amout, 1 NXT fee, 510 NXT for full block. 320+156*255 = 40100 bytes of memory.
According to guide (https://nextcoin.org/index.php/topic,1277.msg10730/topicseen.html#msg10730), JRE in RPi can use up to 430Mb for heap. Okey, let's assume, that 401Mb is available for blocks and transactions. 401M / 40100 = 10000. Yes, just ten thousand blocks, and you RPi is dead. Or 5M NXT. F*ckin five million coins.

This is very rough calculations. Very. My intuition tell me, that things are worse actually. Cheeper. Faster.
And then, after RPi, this attack will kill cheap 2Gb VPS's. And then - 32-bit JRE's, which actually hardly can get 2Gb of heap.
And before that we will hear the song of death from our HDD/SSD, tired to save that .nxt files everytime you get new fat block.

Solution?
I think devs know it and has in TODO list :) We need to use some embedded DB and cache in memory only what we need right now: couple of last blocks.


Title: Re: Nxt source code analysis (QA)
Post by: msin on January 05, 2014, 05:58:48 AM
Thanks ImmortAlex, please keep up the excellent analysis.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 05, 2014, 06:17:29 AM
Kind of Post Scriptum to previous analysis.

1. Java and it's unpredictable object's size, nice article (http://habrahabr.ru/post/164777/) in russian (sorry, guys :) ).
2. For those who don't look deeper: 10000 blocks is just 10 days in current rate (AFAIK (http://87.230.14.1/nxt/nxt.cgi?action=40&sub=2), we're still not getting desired 1440 blocks per day). Ten days to kill big part of our decentralized network. And ten days more to kill the rest.
3. There will be short-time paradise for miners :) 255 coins every minute. Wow.
4. I believe that if such kind of attack will start, devs fix the problem in one or two day, so it is actually not a reason to sell you coins. Just some funsy math. Do you remember how fast C-f-B redo NRS from self-written http code to Jetty? Moving blockchain to DBMS is the same, more or less.


Title: Re: Nxt source code analysis (QA)
Post by: mczarnek on January 05, 2014, 07:50:54 AM
About what I figured.. though I am surprised that it's all in one file and you are saying that only one person can work on it at a time.

It may take more time right now but I say fix any big bugs so people don't lose their money, then first thing you should do is refactor the code, split it up, and allow multiple people to work on it.

I read as much as I could about the idea behind Nextcoin and if you guys pull this off, most of the people reading this will make a lot of money off of it, a few years from now.. this fixes all the major problems with Bitcoin and I think it's genius.  Seriously this is by far the best idea for a crypto I've seen yet.

But it needs a lot of work to get there.. and in order to do so, I feel like you are going to need a team and to subversion it.


Title: Re: Nxt source code analysis (QA)
Post by: Meizirkki on January 05, 2014, 08:00:24 AM
ImmortAlex deserves a flood of donations for his work :)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 08:06:05 AM
ImmortAlex deserves a flood of donations for his work :)

Agree. 10K sent to the account in his signature.


Title: Re: Nxt source code analysis (QA)
Post by: mczarnek on January 05, 2014, 08:29:55 AM
Good thinking, thanks for your work ImmortAlex!

Also maybe not the place for it, but a suggestion, what if say 1% of all the transaction fees went into a specific wallet to be used for paying people to develop the code?

Seems to me like it'd be nice to support the developers, and when we have our own Nextcoin foundation similar to the Bitcoin foundation, we could have automatic funds to be always developing and improving the currency, so Nextcoin always has some funds to improve itself.  And there are so many directions this idea could be taken!  Nextcoin is going to be amazing some day.

Something you'd have to have people vote on of course..  or maybe a better solution that I all around like better, put an optional radio button in every forger's wallet that says donate O-0% O-1%(default?) O-2% O-3% O-4% of all my NXT forged to the 'Nextcoin Foundation'.

Short term, I think it'd bring some peace of mind to people that these problems will be fixed and you'll be able to pay people to fix them and have a stronger development team behind the project.  Because I'll be honest the code scares me a little seeing how much work is needed to really compete against other cryptos.

Though I suspect the current developers are largely initial investors, who do still have a bunch of NXT of their own at this point to provide them with some incentive :)


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 05, 2014, 08:58:21 AM
ImmortAlex deserves a flood of donations for his work :)

Agree. 10K sent to the account in his signature.
Cпacибo бoльшoe! Пpигoдитcя.


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 05, 2014, 09:04:20 AM
Also maybe not the place for it, but a suggestion, what if say 1% of all the transaction fees went into a specific wallet to be used for paying people to develop the code?
Developers interested theirself to develop Nxt software and rise interest to Nxt because it rises cost ot their existing Nxt funds.
I don't think that any additional fee is needed. Donations are welcome as usual, but no more.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 12:43:01 PM
For people who are completely dismayed with the poor quality of the NXT code base and believe they can do better,  then please join this new project:  https://bitcointalk.org/index.php?topic=398461.msg4305172

Your input will be welcome.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 12:50:13 PM
Kind of Post Scriptum to previous analysis.

1. Java and it's unpredictable object's size, nice article (http://habrahabr.ru/post/164777/) in russian (sorry, guys :) ).
2. For those who don't look deeper: 10000 blocks is just 10 days in current rate (AFAIK (http://87.230.14.1/nxt/nxt.cgi?action=40&sub=2), we're still not getting desired 1440 blocks per day). Ten days to kill big part of our decentralized network. And ten days more to kill the rest.
3. There will be short-time paradise for miners :) 255 coins every minute. Wow.
4. I believe that if such kind of attack will start, devs fix the problem in one or two day, so it is actually not a reason to sell you coins. Just some funsy math. Do you remember how fast C-f-B redo NRS from self-written http code to Jetty? Moving blockchain to DBMS is the same, more or less.

That's why bitcoind uses leveldb.  It would be joke to keep the entire block chain in memory.

So you are saying this NXT keeps the entire block chain in memory?  

Pathetic.

I mean, they likely haven't done any analysis of what kind of database to use as a backend.   There is no way that they'll be able to fix this problem in time for folks to realize that they can spam the network and blow up every JVM that sits on this network!

Well... clock is ticking....  waiting on the dbms implementation....

Also,  realize that they use Java serialization to store the transactions in file....  

So when these JVMs go 'out of memory error'... they can't save the transactions file.... and even if they do... that'll blow up!

HILARIOUS!

DO I GET THE PRIZE FOR SEEING THE FATAL FLAW!





Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 12:56:35 PM
Next step is to calculate cost of attack.
Attacker can send 255 transactions in block. Let's use simple ordinary payment, 1 NXT amout, 1 NXT fee, 510 NXT for full block. 320+156*255 = 40100 bytes of memory.
According to guide (https://nextcoin.org/index.php/topic,1277.msg10730/topicseen.html#msg10730), JRE in RPi can use up to 430Mb for heap. Okey, let's assume, that 401Mb is available for blocks and transactions. 401M / 40100 = 10000. Yes, just ten thousand blocks, and you RPi is dead. Or 5M NXT. F*ckin five million coins.


You can just use one NXT and bounce it around the network!

In fact, since everything is all HTTP based.  Someone can write a script.

Create 1000 accounts
Loop 10,000 times
    Loop through each account
        Send 1 IXC to each account





Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 01:04:30 PM
DO I GET THE PRIZE FOR SEEING THE FATAL FLAW!

Sorry, no. All data is supposed to be kept in virtual memory and be accessible via memory mapped files. This is what "blockchain.nrs" for.

Bitcoin already got a very serious problem coz of using 3rd party data storage software (leveldb). U should read more than u write. ;)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 01:18:29 PM
Your ignorance completely surprises me.

If you allocate 1 GB for your JVM instance,  then 1GB is all you have.   Now that data can indeed go into virtual memory (i.e. disk),  but it still is confined to 1GB.

http://ic.pics.livejournal.com/crims/46694867/28655/28655_900.jpg


U can map terabytes into this 1 GB and OS will does its best to feed the data as fast as possible.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 01:20:24 PM
DO I GET THE PRIZE FOR SEEING THE FATAL FLAW!

Sorry, no. All data is supposed to be kept in virtual memory and be accessible via memory mapped files. This is what "blockchain.nrs" for.

Bitcoin already got a very serious problem coz of using 3rd party data storage software (leveldb). U should read more than u write. ;)

Still not convinced you have a handle on your memory problem just because you are using Java nio.   Did you happen to have coded a memory caching algorithm so that your java code knows when to take and replace what's in your memory mapped file?  I doubt it,  that would be akin to writing your own object oriented database.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 01:20:56 PM
Create 1000 accounts
Loop 10,000 times
    Loop through each account
        Send 1 IXC to each account

U mean NXT I believe.

PS: Aye, let's make miners happy!


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 01:22:01 PM
Your ignorance completely surprises me.

If you allocate 1 GB for your JVM instance,  then 1GB is all you have.   Now that data can indeed go into virtual memory (i.e. disk),  but it still is confined to 1GB.

http://ic.pics.livejournal.com/crims/46694867/28655/28655_900.jpg


U can map terabytes into this 1 GB and OS will does its best to feed the data as fast as possible.

You can feed the data into the memory mapped file,  but can you pull it out?

Duh!!! Triple face palm!


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 01:22:16 PM
Still not convinced you have a handle on your memory problem just because you are using Java nio.   Did you happen to have coded a memory caching algorithm so that your java code knows when to take and replace what's in your memory mapped file?  I doubt it,  that would be akin to writing your own object oriented database.

Man, I see u r so stupid not so smart, so I'll put u back into ignore list for a week. C u later.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 01:24:32 PM
Still not convinced you have a handle on your memory problem just because you are using Java nio.   Did you happen to have coded a memory caching algorithm so that your java code knows when to take and replace what's in your memory mapped file?  I doubt it,  that would be akin to writing your own object oriented database.

Man, I see u r so stupid not so smart, so I'll put u back into ignore list for a week. C u later.

I guess your answer to my query was.... "I guess I didn't think about that... will go back to the drawing board and try to figure this out.... see you in a week."

Well let's hope that NXT is still alive in a week's time.


Title: Re: Nxt source code analysis (QA)
Post by: Meizirkki on January 05, 2014, 01:28:34 PM
Kind of Post Scriptum to previous analysis.

1. Java and it's unpredictable object's size, nice article (http://habrahabr.ru/post/164777/) in russian (sorry, guys :) ).
2. For those who don't look deeper: 10000 blocks is just 10 days in current rate (AFAIK (http://87.230.14.1/nxt/nxt.cgi?action=40&sub=2), we're still not getting desired 1440 blocks per day). Ten days to kill big part of our decentralized network. And ten days more to kill the rest.
3. There will be short-time paradise for miners :) 255 coins every minute. Wow.
4. I believe that if such kind of attack will start, devs fix the problem in one or two day, so it is actually not a reason to sell you coins. Just some funsy math. Do you remember how fast C-f-B redo NRS from self-written http code to Jetty? Moving blockchain to DBMS is the same, more or less.

That's why bitcoind uses leveldb.  It would be joke to keep the entire block chain in memory.

So you are saying this NXT keeps the entire block chain in memory?  

Pathetic.

I mean, they likely haven't done any analysis of what kind of database to use as a backend.   There is no way that they'll be able to fix this problem in time for folks to realize that they can spam the network and blow up every JVM that sits on this network!

Well... clock is ticking....  waiting on the dbms implementation....

Also,  realize that they use Java serialization to store the transactions in file....  

So when these JVMs go 'out of memory error'... they can't save the transactions file.... and even if they do... that'll blow up!

HILARIOUS!

DO I GET THE PRIZE FOR SEEING THE FATAL FLAW!
*Applause*

All you do is come around and flip shit on every nxt thread. If the code is so shit just fix it and move on to making the fork you were planning.


Title: Re: Nxt source code analysis (QA)
Post by: instacalm on January 05, 2014, 01:31:20 PM
Well let's hope that NXT is still alive in a week's time.

Stop being like that FrictionlessCoin, what's your use of being so bothersome? From a psychological standpoint it is obvious that those posts of yours derive from jealousy.

You think you are so great... yet there is nothing worthwhile of yours to see? Where's constructive criticism? Where is your from scratch next gen currency? All I can see is that you are trying to push a dead ship called IXCoin, that's it. Face it and redefine yourself, please. It is boring to read your posts, you know?


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 01:55:29 PM
Kind of Post Scriptum to previous analysis.

1. Java and it's unpredictable object's size, nice article (http://habrahabr.ru/post/164777/) in russian (sorry, guys :) ).
2. For those who don't look deeper: 10000 blocks is just 10 days in current rate (AFAIK (http://87.230.14.1/nxt/nxt.cgi?action=40&sub=2), we're still not getting desired 1440 blocks per day). Ten days to kill big part of our decentralized network. And ten days more to kill the rest.
3. There will be short-time paradise for miners :) 255 coins every minute. Wow.
4. I believe that if such kind of attack will start, devs fix the problem in one or two day, so it is actually not a reason to sell you coins. Just some funsy math. Do you remember how fast C-f-B redo NRS from self-written http code to Jetty? Moving blockchain to DBMS is the same, more or less.

That's why bitcoind uses leveldb.  It would be joke to keep the entire block chain in memory.

So you are saying this NXT keeps the entire block chain in memory?  

Pathetic.

I mean, they likely haven't done any analysis of what kind of database to use as a backend.   There is no way that they'll be able to fix this problem in time for folks to realize that they can spam the network and blow up every JVM that sits on this network!

Well... clock is ticking....  waiting on the dbms implementation....

Also,  realize that they use Java serialization to store the transactions in file....  

So when these JVMs go 'out of memory error'... they can't save the transactions file.... and even if they do... that'll blow up!

HILARIOUS!

DO I GET THE PRIZE FOR SEEING THE FATAL FLAW!
*Applause*

All you do is come around and flip shit on every nxt thread. If the code is so shit just fix it and move on to making the fork you were planning.

You know why I hang out in the Nxt threads?

Because you can learn a lot from the mistakes of others.



Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 01:56:51 PM
Well let's hope that NXT is still alive in a week's time.

Stop being like that FrictionlessCoin, what's your use of being so bothersome? From a psychological standpoint it is obvious that those posts of yours derive from jealousy.

You think you are so great... yet there is nothing worthwhile of yours to see? Where's constructive criticism? Where is your from scratch next gen currency? All I can see is that you are trying to push a dead ship called IXCoin, that's it. Face it and redefine yourself, please. It is boring to read your posts, you know?

I am not the only person who is warning you folks about the NXT memory problem.

The other dude (Alex something) is saying a similar thing.

If this thing is not fixed quickly... then this is a dead coin very quickly.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 02:01:35 PM
Where is your from scratch next gen currency? All I can see is that you are trying to push a dead ship called IXCoin, that's it. Face it and redefine yourself, please. It is boring to read your posts, you know?

Solid technology is not written in a short time.  I takes weeks or months to create something really solid.  Not like NXT that was written in less than a week.  Take for example eMunie,  the guy has been working for 6 months already and he has not launched yet.   The Next Gen Currency (TNG) takes time.

iXcoin... has like 5 peta hash per second in its network.   It may not be as popular today as DOGEcoin but the applications of such a network are tremendous and I see it as a good platform that a lot of people would like to leverage.  

My interest in NXT however is more on the lines of 'what not to do when creating a new coin'.  It is always cheaper to learn from other people's mistakes.  Kind of like the Edsel which was a flop, but it was followed by the Ford Mustang which was wildly successful.  So as I learn from NXT mistakes,  I can build a better Next Gen Currency.  Hmm... (NGC) has a nice ring to it.


Title: Re: Nxt source code analysis (QA)
Post by: ciappa on January 05, 2014, 02:24:00 PM
Hello,

I speak very bad English!
Can anyone explain what happened to someone nextcoin easy? Is the source code so bad?

thank you


Title: Re: Nxt source code analysis (QA)
Post by: NxtChoice on January 05, 2014, 02:29:45 PM

The core of Nxt is the idea and thought of Nxt, say TF.  Software engineering and database are important, but they are not beyond the present technology. We can do it even in a short time. The stakeholders will donate to hire more DB experts, and I will also donate if some one organize it.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 03:00:55 PM

The core of Nxt is the idea and thought of Nxt, say TF.  Software engineering and database are important, but they are not beyond the present technology. We can do it even in a short time. The stakeholders will donate to hire more DB experts, and I will also donate if some one organize it.


Ideas are a dime a dozen.

I am not sure if NXT has any good ideas.

But rest assured,  if I discover that it does,  then it will be incorporated in the Next Gen Currency (NGC).


Title: Re: Nxt source code analysis (QA)
Post by: nexern on January 05, 2014, 03:02:20 PM
Hello,

I speak very bad English!
Can anyone explain what happened to someone nextcoin easy? Is the source code so bad?

thank you

no, a tiny brain (FrictionlessCoin) is far overwhelmed to read the code that way to understand
the inner workflow and desperately trying to cover his more than once showed insufficient
knowledge by focusing on code beauty details. instead stopping this before it's going more
and more ridiculous for him, he is to long on this road, so (unfortunatly for him) he has to
go on with this nonsens.

this code review has added some very good improvements so far from some very good java
coder but nobody has found any serious problem nor the flaws as far i can see.

please correct me if i am wrong.


Title: Re: Nxt source code analysis (QA)
Post by: instacalm on January 05, 2014, 03:09:47 PM
I am not sure if NXT has any good ideas.

Every post you provided has proven that you are indeed clueless.

I've said it before, if you think you are oh so great then prove it. Until now there's nothing, nada, except your envy.

Last post dedicated to you. Back to topic, source code analysis.


Title: Re: Nxt source code analysis (QA)
Post by: achimsmile on January 05, 2014, 03:13:05 PM
no, a tiny brain (FrictionlessCoin) is far overwhelmed to read the code that way to understand
the inner workflow and desperately trying to cover his more than once showed insufficient
knowledge by focusing on code beauty details. instead stopping this before it's going more
and more ridiculous for him, he is to long on this road, so (unfortunatly for him) he has to
go on with this nonsens.

this code review has added some very good improvements so far from some very good java
coder but nobody has found any serious problem nor the flaws as far i can see.

please correct me if i am wrong.


Can't correct you, IMO everything in your post is true!


Title: Re: Nxt source code analysis (QA)
Post by: ciappa on January 05, 2014, 03:20:11 PM
ok, so what you're saying is that the entire next code is not good? Is next doomed to fail?


Title: Re: Nxt source code analysis (QA)
Post by: nexern on January 05, 2014, 03:26:54 PM
ok, so what you're saying is that the entire next code is not good? Is next doomed to fail?

code -> good -> nxt -> good


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 03:29:00 PM
ok, so what you're saying is that the entire next code is not good? Is next doomed to fail?

code -> good -> nxt -> good

code -> bad -> bugs -> fail


Title: Re: Nxt source code analysis (QA)
Post by: bitcoinpaul on January 05, 2014, 03:32:57 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.


Title: Re: Nxt source code analysis (QA)
Post by: nexern on January 05, 2014, 04:50:53 PM
because it fit's into this thread just on thing which has attract my attention.

i have to admit that i am not a native java coder and i just have had a quick look at
the api part due to the client dev, therefore this could be nonsens but for me, the code
structure seems that the creator intentionally veiled his native codingstyle.

if so, i bet the flaws couldn't be found by hunting partial code strucs but more within the
logical flow in general. moreover, if this is correct, the energy needed to change a perhaps
long used coding style this way must be immense. at least there is no chance to get any
usefull code correlation this way.

as said, it could be totally wrong but i have seen many lines of code in different
languages, this structure doesn't seems coincidental for me.

perhaps a fluent java coder could have a quick overview again, with this in mind.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 04:55:14 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



Title: Re: Nxt source code analysis (QA)
Post by: bitcoinpaul on January 05, 2014, 04:56:54 PM
because it fit's into this thread just on thing which has attract my attention.

i have to admit that i am not a native java coder and i just have had a quick look at
the api part due to the client dev, therefore this could be nonsens but for me, the code
structure seems that the creator intentionally veiled his native codingstyle.

if so, i bet the flaws couldn't be found by hunting partial code strucs but more within the
logical flow in general. moreover, if this is correct, the energy needed to change a perhaps
long used coding style this way must be immense. at least there is no chance to get any
usefull code correlation this way.

as said, it could be totally wrong but i have seen many lines of code in different
languages, this structure doesn't seems coincidental for me.

perhaps a fluent java coder could have a quick overview again, with this in mind.

Interesting.


Title: Re: Nxt source code analysis (QA)
Post by: bitcool on January 05, 2014, 05:00:15 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



I do think your job here is valuable, most points are valid.

Burying head in the sand and resisting any criticism are not good for any community's health.


Title: Re: Nxt source code analysis (QA)
Post by: bitcool on January 05, 2014, 05:04:36 PM
because it fit's into this thread just on thing which has attract my attention.

i have to admit that i am not a native java coder and i just have had a quick look at
the api part due to the client dev, therefore this could be nonsens but for me, the code
structure seems that the creator intentionally veiled his native codingstyle.

if so, i bet the flaws couldn't be found by hunting partial code strucs but more within the
logical flow in general. moreover, if this is correct, the energy needed to change a perhaps
long used coding style this way must be immense. at least there is no chance to get any
usefull code correlation this way.

as said, it could be totally wrong but i have seen many lines of code in different
languages, this structure doesn't seems coincidental for me.

perhaps a fluent java coder could have a quick overview again, with this in mind.

Very possible. The whole application running as a servlet in Jetty web server, it needs to interact w/ the servlet container.

It's not a good practice for applications taking control of threads directly,  and that destroy() method looks disturbing.



 


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 05:05:45 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



I do think your job here is valuable, most points are valid.

Burying head in the sand and resisting any criticism are not good for any community's health.

If I were an investor,  I would like to know all the warts of what I'm investing in.  

My main coins I've invested in are BTC, LTC, NMC and IXC.  I have done my due diligence and I know exactly what their Pros and Cons are.   We aren't talking play money here anymore,  this is serious money.

So if people want to bury the truth, then that's there problem.



Title: Re: Nxt source code analysis (QA)
Post by: ciappa on January 05, 2014, 05:11:47 PM
Now are 2 nextcoin exchanges!

Dgex.com and nxtchg.com !

Why cryptsy, bter, vircurex etc. dont can trade nextcoins?


Title: Re: Nxt source code analysis (QA)
Post by: empowering on January 05, 2014, 05:15:18 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



Show us what you have got then... apart from a terrible bedside manner ; )

So far from reading your posts it seems that far from being an expert, you seem to be quick to jump to conclusions , which show that you do not even read English properly, let alone code, and you are behaving in a way that is a little bit childish...  I note there are obviously some real experts that have been providing valuable and thoughtful/well though out intelligent feedback, what you are doing is some sort of constant bickering attack.  There is nothing wrong with being nice, thoughtful, and treating people and their work with some respect, and frankly even if your motives are good, which I question, then if you are trying to help people, then be a nice guy about it!  you may have more joy in actually helping people, because to help people you need to communicate wth people to get them to listen, not attack,  and at the end of the day if you are not helping, then you are just in the way, and if you are helping then how about a dose of humility and common decency along with that good deed?  You know, try not to be a jerk about it,  otherwise it is not avery attractive way to carry on, and will get you nothing in life. Just think about it.

Back on topic.  


Title: Re: Nxt source code analysis (QA)
Post by: nexern on January 05, 2014, 05:25:00 PM
Now are 2 nextcoin exchanges!

Dgex.com and nxtchg.com !

Why cryptsy, bter, vircurex etc. dont can trade nextcoins?

questo thread è per l'analisi del codice ciappa. meglio chiedere questo direttamente
al thread principale, guardate qui -> https://bitcointalk.org/index.php?topic=345619.14720


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 05:39:41 PM
ok, so what you're saying is that the entire next code is not good? Is next doomed to fail?

code -> good -> nxt -> good

code -> bad -> bugs -> fail

Frictionless clearly you want to make your own NXT and get chunk of genesis block. It seems someone was foolish enough to send you 100BTC?? I guess that wasn't enough for you, so you want to convince people how good you are at writing code.

Show me your skills. Post a single bug, however trivial that is actually a bug and not style. I have a lot of C experience, unfortunately not java, but enough similarities to be able to find bugs left and right if it was truly amateurish. After spending hours trying to find even off by one errors, I mostly found out that it was my off by one errors and the codes simplicity (in control flow) masks the complexity it was implementing.

Anybody can write lots of code to solve a complicated problem
Few can write a little code to solve a complicated problem

Fewer can write 4000 lines of code to create bitcoin level functionality, let alone what NXT has implemented with a few thousand more lines of "secret sauce" code. It is good that it was not released so you have to wait until april to release your super fantastic perfectly software engineered NGC coin that will just be a NXT copycat, even if you pay to refactor the current source code in the meatime. Good luck finding more fools to buy your coin.

James

P.S. I know there are ~6800 lines, I subtracted 3,000 lines of code due to inclusion of curve code, bignum code, hardcoding of genesis block and other data arrays and of course the plentiful blank lines. NXT core is only 4000 lines of java code that will run on cellphones. That does not fit my definition of amateur.


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 05:42:33 PM
Now are 2 nextcoin exchanges!

Dgex.com and nxtchg.com !

Why cryptsy, bter, vircurex etc. dont can trade nextcoins?

You can also trade NXT on ripple using peercover, link in my sig

James


Title: Re: Nxt source code analysis (QA)
Post by: ciappa on January 05, 2014, 06:02:20 PM
Thanks for your reply, I have now seen!
But I'm interested because nextcoin is already a significant crypto currency is not traded in cryptsy & Co?


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 06:30:06 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



Show us what you have got then... apart from a terrible bedside manner ; )

So far from reading your posts it seems that far from being an expert, you seem to be quick to jump to conclusions , which show that you do not even read English properly, let alone code, and you are behaving in a way that is a little bit childish...  I note there are obviously some real experts that have been providing valuable and thoughtful/well though out intelligent feedback, what you are doing is some sort of constant bickering attack.  There is nothing wrong with being nice, thoughtful, and treating people and their work with some respect, and frankly even if your motives are good, which I question, then if you are trying to help people, then be a nice guy about it!  you may have more joy in actually helping people, because to help people you need to communicate wth people to get them to listen, not attack,  and at the end of the day if you are not helping, then you are just in the way, and if you are helping then how about a dose of humility and common decency along with that good deed?  You know, try not to be a jerk about it,  otherwise it is not avery attractive way to carry on, and will get you nothing in life. Just think about it.

Back on topic.  

Simon Cowell of American Idol sounded like a complete jerk from his criticism.  but their were honest and spot on.

I'm telling you how it is,  this stuff is shoddy work.  I'm not the only one saying this.  Just saying it like it is.

If you expect me to sound nice on code that is supposed to secure someone's money,  then you aren't going to hear that from me.  This is a serious business and if you can't take the heat, get out of the business.


Title: Re: Nxt source code analysis (QA)
Post by: klee on January 05, 2014, 06:31:53 PM
Hey Freak did you finally find a bf here? You damn attention whore ;)


Title: Re: Nxt source code analysis (QA)
Post by: salsacz on January 05, 2014, 06:47:17 PM
hello experts,
I am gathering your citations about the code and about BCNext, for videos and video documents... I would like to ask you if you can write about the ideas implemented in the code, if it is innovative and maybe - how smart is BCNext? Can we compare him with any scientist/inventor? It can be only 1-2 sentences...

I've got:

xibeijan

Quote
NXT's beauty is in the algorithms and maths that have brought forward the state-of-the-art.  I seriously doubt the creator cares about keeping tidy with the code.  In fact, I know quite a few genius computer scientists who produce really ugly, stupid code.  However, that doesn't matter one iota when the algorithms are groundbreakingly better than anything that's come before.

Our investment is in the extremely clever people behind the NXT project.  Computer science and software engineering, though related, are different things.  I am glad the NXT has a computer scientist like BCNext behind it who actually has new ideas and can bring them to life, no matter how messy the code may be.  New capabilities are something that has been missing from every other alt coin that has come before NXT.

As I said, some really great computer scientists do not follow great software engineering principles, but their code does things no one else's can.  And that, my friend, is the point.

Bcnext is a freaking genius. I worked so hard to try to figure something out like this myself to no avail. What i proposed in my thread is a far cry from this much better solution.

That we are not investing in source code, we are investing in the algorithms, the big ideas (BCNext) and the huge community supporting NXT.

Computer science and software engineering, though related, are different things.  I am glad the NXT has a computer scientist like BCNext behind it who actually has new ideas and can bring them to life, no matter how messy the code may be.  New capabilities are something that has been missing from every other alt coin that has come before NXT.


rlh
Quote
I know that this is about fees and not generating currency, but the concept of adjusting system metrics, based off daily transactional statistics is something I've looked at and thought about for a loooooong time.  I think we could do the same type of thing here.

tk808
Quote
This is the real-world dude, not an algorithm found in a textbook

You can post it here or as PM, thank you!!


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 07:04:28 PM
because it fit's into this thread just on thing which has attract my attention.

i have to admit that i am not a native java coder and i just have had a quick look at
the api part due to the client dev, therefore this could be nonsens but for me, the code
structure seems that the creator intentionally veiled his native codingstyle.

if so, i bet the flaws couldn't be found by hunting partial code strucs but more within the
logical flow in general. moreover, if this is correct, the energy needed to change a perhaps
long used coding style this way must be immense. at least there is no chance to get any
usefull code correlation this way.

as said, it could be totally wrong but i have seen many lines of code in different
languages, this structure doesn't seems coincidental for me.

perhaps a fluent java coder could have a quick overview again, with this in mind.

Very possible. The whole application running as a servlet in Jetty web server, it needs to interact w/ the servlet container.

It's not a good practice for applications taking control of threads directly,  and that destroy() method looks disturbing.
 

Not only that,  did you realize that the wallet is also exposed to the public internet?   That there is not mechanism to prevent a brute force password attack?   

In theory, it is not good practice to spawn of thread inside a servlet container.






Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 07:07:56 PM
You know why I hang out in the Nxt threads?

You write some garbage and you get honest answers from CfB. You are trolling around to learn a few tricks from CfB. This is just dishonorable.

I have the impression you don't want to be friendly and nice, FrictionlessCoin. Please, just go. Thank you.

If you are an expert in a field and you see an amateur do very shoddy work, the I think one would have the responsibility of pointing this out.

The work here is plain and simple shoddy.

Maybe the ideas may make sense (don't know,  I have not seen the spec),  but the work is shoddy.



Show us what you have got then... apart from a terrible bedside manner ; )


bitcoin-ng.boards.net   join the development!


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 07:17:55 PM
because it fit's into this thread just on thing which has attract my attention.

i have to admit that i am not a native java coder and i just have had a quick look at
the api part due to the client dev, therefore this could be nonsens but for me, the code
structure seems that the creator intentionally veiled his native codingstyle.

if so, i bet the flaws couldn't be found by hunting partial code strucs but more within the
logical flow in general. moreover, if this is correct, the energy needed to change a perhaps
long used coding style this way must be immense. at least there is no chance to get any
usefull code correlation this way.

as said, it could be totally wrong but i have seen many lines of code in different
languages, this structure doesn't seems coincidental for me.

perhaps a fluent java coder could have a quick overview again, with this in mind.

Very possible. The whole application running as a servlet in Jetty web server, it needs to interact w/ the servlet container.

It's not a good practice for applications taking control of threads directly,  and that destroy() method looks disturbing.
 

Not only that,  did you realize that the wallet is also exposed to the public internet?   That there is not mechanism to prevent a brute force password attack?   

In theory, it is not good practice to spawn of thread inside a servlet container.






Gee, would it really freak you out if you found out you can do an OFFLINE brute force attack?
Just need to scan 64 bits and pick up all the darkNXT and 256 bits to crack everybody's acct. But hurry, you only have until shortly after API 2.0, cuz there will be a second 256 bit key on all the big accts, plus wallet fragmentation.

Pretty amateurish, isn't it, us taking security to 256 bits twice. Some criticize it is overkill on security. At least you can keep complaining without coming up with ANY actual flaws in the code, even trivial off by one errors. School kids usually write so many such errors, strange we haven't found a single one.

James


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 07:22:26 PM
hello experts,
I am gathering your citations about the code and about BCNext, for videos and video documents... I would like to ask you if you can write about the ideas implemented in the code, if it is innovative and maybe - how smart is BCNext? Can we compare him with any scientist/inventor? It can be only 1-2 sentences...

I've got:

xibeijan

Quote
NXT's beauty is in the algorithms and maths that have brought forward the state-of-the-art.  I seriously doubt the creator cares about keeping tidy with the code.  In fact, I know quite a few genius computer scientists who produce really ugly, stupid code.  However, that doesn't matter one iota when the algorithms are groundbreakingly better than anything that's come before.

Our investment is in the extremely clever people behind the NXT project.  Computer science and software engineering, though related, are different things.  I am glad the NXT has a computer scientist like BCNext behind it who actually has new ideas and can bring them to life, no matter how messy the code may be.  New capabilities are something that has been missing from every other alt coin that has come before NXT.

As I said, some really great computer scientists do not follow great software engineering principles, but their code does things no one else's can.  And that, my friend, is the point.

Bcnext is a freaking genius. I worked so hard to try to figure something out like this myself to no avail. What i proposed in my thread is a far cry from this much better solution.

That we are not investing in source code, we are investing in the algorithms, the big ideas (BCNext) and the huge community supporting NXT.

Computer science and software engineering, though related, are different things.  I am glad the NXT has a computer scientist like BCNext behind it who actually has new ideas and can bring them to life, no matter how messy the code may be.  New capabilities are something that has been missing from every other alt coin that has come before NXT.


rlh
Quote
I know that this is about fees and not generating currency, but the concept of adjusting system metrics, based off daily transactional statistics is something I've looked at and thought about for a loooooong time.  I think we could do the same type of thing here.

tk808
Quote
This is the real-world dude, not an algorithm found in a textbook

You can post it here or as PM, thank you!!

BCnext is the Tesla (the man, not car) of crypto currency. With simple control flow, he has created the NXT network in about 4000 lines of code. Like Tesla's designs that few people understand, the magic constants used, happen to just work. BCnext has utilized the numerical properties of numbers themselves to create a peer to peer crypto with pretty much all the features any other crypto has conceived, in ~4000 lines of java that runs on cellphones!

James


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 08:16:03 PM
Since setBalance can throw, where you do the following, balance and unconfirmed balance can get out of sync:

Code:
generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);

Code:
void setBalance(long balance) throws Exception {
    this.balance = balance;
    for (Peer peer : peers.values()) {
    if (peer.accountId == id && peer.adjustedWeight > 0) {
        peer.updateWeight();
    }
}

Granted, this is unlikely since you are suppressing all exceptions around the network calls. But it might be more robust to calculate balance from unconfirmedbalance or vice-versa.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 08:17:13 PM
Since setBalance can throw, where you do the following, balance and unconfirmed balance can get out of sync:

Code:
generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);

Code:
void setBalance(long balance) throws Exception {
    this.balance = balance;
    for (Peer peer : peers.values()) {
    if (peer.accountId == id && peer.adjustedWeight > 0) {
        peer.updateWeight();
    }
}

Granted, this is unlikely since you are suppressing all exceptions around the network calls. But it might be more robust to calculate balance from unconfirmedbalance or vice-versa.

Jean-Luc was going to fix this issue AFAIK.


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 08:28:52 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}

Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely

But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions.

Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently).

This extra locking can help scalability down the road.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 08:37:54 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}

Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely

But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions.

Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently).

This extra locking can help scalability down the road.

Yeah,  let's just throw as many synchronized blocks all over the place because we really don't know what we're doing.

I would have been impressed if the code didn't use a single synchronized block.  That would be an indication of a very well designed system.

Sigh.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 08:43:29 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}

Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely

But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions.

Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently).

This extra locking can help scalability down the road.

Valid points, but there was a special rule set - code must be readable by a novice programmer. Concurrent API is for more experienced programmers. I used Concurrent API in my code a couple of times but I was trying to follow the rule.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 08:43:53 PM
My favorite snippet of code:

Code:
catch (Exception e) { }

More than 18 times in the code.

Reminds me of all these coin holders who have their head in the sand.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 08:49:58 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}

Since all you are really doing is setting a transaction number, you should be using AtomicInteger. This would eliminate the lock completely

But, in general, you should consider minimizing the scopes of your locks. For example, here, you're locking the entire transactions array to update a single transaction. It would be better to lock around that specific transaction so as not to block other pieces of code attempting to inspect / edit other transactions.

Also, there are a number of places where reader-writer locks are more appropriate than using synchronized (e.g. when dealing users, which should change relatively infrequently).

This extra locking can help scalability down the road.

Valid points, but there was a special rule set - code must be readable by a novice programmer. Concurrent API is for more experienced programmers. I used Concurrent API in my code a couple of times but I was trying to follow the rule.

Maybe you should rephrase that "code must be writable by a novice programmer who has never understood Java concurrent api."

So you're saying you made up a rule to hide your ignorance.  "Thou shall not use concurrent API because I don't understand it"


Title: Re: Nxt source code analysis (QA)
Post by: tacotime on January 05, 2014, 08:53:29 PM
My favorite snippet of code:

Code:
catch (Exception e) { }

More than 18 times in the code.

Reminds me of all these coin holders who have their head in the sand.

For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 08:58:29 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:03:08 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like,  if I see some kind of error,  let me keep quiet about it!


Title: Re: Nxt source code analysis (QA)
Post by: User705 on January 05, 2014, 09:12:20 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like,  if I see some kind of error,  let me keep quiet about it!
Can you explain how that would effect the actual functionality of the system.  Isn't it the same as someone submitting improperly signed transactions so those should be ignored?  You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up.


Title: Re: Nxt source code analysis (QA)
Post by: lwilliams777 on January 05, 2014, 09:20:26 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Title: Re: Nxt source code analysis (QA)
Post by: tacotime on January 05, 2014, 09:20:37 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like, if I see some kind of error,  let me keep quiet about it!
Can you explain how that would effect the actual functionality of the system.  Isn't it the same as someone submitting improperly signed transactions so those should be ignored?  You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up.

It depends where you put it... it's dangerous in most places though because it doesn't class or report the exception and prevent you from seeing any other bugs that might arise while a function is executing.  Basically: "Regardless of the error that arises, keep running and do not report it."

http://stackoverflow.com/questions/2416316/why-is-the-catchexception-almost-always-a-bad-idea

It's what I write when I'm in a rush and don't really care when I get some kind of error so long as the program does more or less what I want it to; ideally you would address it properly, but if you're writing something like a program for something non-critical it doesn't really matter.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 09:22:12 PM
Since setBalance can throw, where you do the following, balance and unconfirmed balance can get out of sync:

Code:
generatorAccount.setBalance(generatorAccount.balance + totalFee * 100L);
generatorAccount.setUnconfirmedBalance(generatorAccount.unconfirmedBalance + totalFee * 100L);

Code:
void setBalance(long balance) throws Exception {
    this.balance = balance;
    for (Peer peer : peers.values()) {
    if (peer.accountId == id && peer.adjustedWeight > 0) {
        peer.updateWeight();
    }
}

Granted, this is unlikely since you are suppressing all exceptions around the network calls. But it might be more robust to calculate balance from unconfirmedbalance or vice-versa.

There is no setBalance() in 0.5.0:

Code:
        synchronized long getBalance() {
            return balance;
        }

        synchronized long getUnconfirmedBalance() {
            return unconfirmedBalance;
        }

        void addToBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;

            }

            updatePeerWeights();

        }
        
        void addToUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.unconfirmedBalance += amount;

            }

            updateUserUnconfirmedBalance();

        }

        void addToBalanceAndUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;
                this.unconfirmedBalance += amount;

            }

            updatePeerWeights();
            updateUserUnconfirmedBalance();

        }


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:22:49 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like,  if I see some kind of error,  let me keep quiet about it!
Can you explain how that would effect the actual functionality of the system.  Isn't it the same as someone submitting improperly signed transactions so those should be ignored?  You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up.

It's in over 18 places in the code.

Anyway,  it is bad practice because if an unexpected error happens (which it always does), you do want to know that something happened.   To assume that you can ignore this because you think you know what you are doing is just bad practice.

Folks,  I don't need to explain to you guys who to write code properly!



Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:25:16 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like, if I see some kind of error,  let me keep quiet about it!
Can you explain how that would effect the actual functionality of the system.  Isn't it the same as someone submitting improperly signed transactions so those should be ignored?  You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up.

It depends where you put it... it's dangerous in most places though because it doesn't class or report the exception and prevent you from seeing any other bugs that might arise while a function is executing.  Basically: "Regardless of the error that arises, keep running and do not report it."

http://stackoverflow.com/questions/2416316/why-is-the-catchexception-almost-always-a-bad-idea

It's what I write when I'm in a rush and don't really care when I get some kind of error so long as the program does more or less what I want it to; ideally you would address it properly, but if you're writing something like a program for something non-critical it doesn't really matter.

Yes, maybe NXT handling money is a non-critical application.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 09:25:48 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}
In 0.5.0 this looks like:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
transaction.index = transactionCounter.incrementAndGet();
I am afraid CfB and BCNext may get mad at me, but 0.5.0 relies heavily on the Concurrent API...


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:27:59 PM

Code:
        synchronized long getBalance() {
            return balance;
        }

        synchronized long getUnconfirmedBalance() {
            return unconfirmedBalance;
        }

        void addToBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;

            }

            updatePeerWeights();

        }
        
        void addToUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.unconfirmedBalance += amount;

            }

            updateUserUnconfirmedBalance();

        }

        void addToBalanceAndUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;
                this.unconfirmedBalance += amount;

            }

            updatePeerWeights();
            updateUserUnconfirmedBalance();

        }

sigh... synchronized (this) ... how ignorant can you get!


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:29:05 PM
There does seem to be a lot of excessive locking. For example:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
synchronized (Nxt.transactions) {
    transaction.index = ++transactionCounter;
}
In 0.5.0 this looks like:
Code:
Transaction transaction = Transaction.getTransaction(buffer);
transaction.index = transactionCounter.incrementAndGet();
I am afraid CfB and BCNext may get mad at me, but 0.5.0 relies heavily on the Concurrent API...

in your dreams.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 09:32:17 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Why would I contribute to what obviously looks like a Ponzi scheme?

You all first explain to me why this entire shenanigan is any different from a Ponzi scheme?


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 09:38:36 PM

Code:
        synchronized long getBalance() {
            return balance;
        }

        synchronized long getUnconfirmedBalance() {
            return unconfirmedBalance;
        }

        void addToBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;

            }

            updatePeerWeights();

        }
        
        void addToUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.unconfirmedBalance += amount;

            }

            updateUserUnconfirmedBalance();

        }

        void addToBalanceAndUnconfirmedBalance(long amount) throws Exception {

            synchronized (this) {

                this.balance += amount;
                this.unconfirmedBalance += amount;

            }

            updatePeerWeights();
            updateUserUnconfirmedBalance();

        }

sigh... synchronized (this) ... how ignorant can you get!

All of those synchronized(this) can be replaced with AtomicInteger.addAndGet


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 09:41:50 PM
I am afraid CfB and BCNext may get mad at me, but 0.5.0 relies heavily on the Concurrent API...

It's ok. Released source code is the whitepaper written in Java. Now we don't need that rule.


Title: Re: Nxt source code analysis (QA)
Post by: lwilliams777 on January 05, 2014, 09:43:07 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Why would I contribute to what obviously looks like a Ponzi scheme?

You all first explain to me why this entire shenanigan is any different from a Ponzi scheme?


Ponzi scheme or no ponzi scheme, what you're doing here doesn't really help.  If you think you are the defender of the naive who are investing then I would ask "Who appointed you the defender".  I think you know the answer.  If you are against the concept of pre-mining I can understand your opposition.  But do you think we can't figure that out for ourselves whether or not to trust pre-mined concepts or not?  Whether or not this is a risky venture or not?  In fact most people in the financial and investment business would consider all virtual systems scams and ponzi schemes.  In any case it is up to the investors to weigh the risks for themselves.  


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 09:45:52 PM
All of those synchronized(this) can be replaced with AtomicInteger.addAndGet

There was a lot of code that looked like:

synchronized (account) {
   1. Check balance
   2. Do something
   3. Adjust balance
}

Is it safe to get rid of synchronized in the quoted code?


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 09:50:21 PM
All of those synchronized(this) can be replaced with AtomicInteger.addAndGet
How about this:
Code:
            synchronized (this) {
                this.balance += amount;
                this.unconfirmedBalance += amount;
            }
Each of them being Atomic by itself will not ensure balance and unconfirmedBalance are both updated atomically, a thread could still see balance incremented but unconfirmedBalance not yet updated.


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 09:52:51 PM
There was a lot of code that looked like:

synchronized (account) {
   1. Check balance
   2. Do something
   3. Adjust balance
}

Is it safe to get rid of synchronized in the quoted code?
It is not, and I haven't.
Code:
			synchronized (account) {

if (account.getUnconfirmedBalance() < amount * 100L) {

doubleSpendingTransaction = true;

} else {

doubleSpendingTransaction = false;

account.addToUnconfirmedBalance(- amount * 100L);

...


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 09:54:58 PM
For the people who don't code, this is essentially, "if you see some kind of error, just ignore it."

;D

Actually not. This is a paradigm heavily used in Erlang (https://en.wikipedia.org/wiki/Erlang_(programming_language)). If u tried to recover after an exception or even logged it, u would just consume resources without real profit.

No,  it's more like,  if I see some kind of error,  let me keep quiet about it!
Can you explain how that would effect the actual functionality of the system.  Isn't it the same as someone submitting improperly signed transactions so those should be ignored?  You keep bringing up issues with the code but without actual explanations of how those issues are supposed to screw things up.

It's in over 18 places in the code.

Anyway,  it is bad practice because if an unexpected error happens (which it always does), you do want to know that something happened.   To assume that you can ignore this because you think you know what you are doing is just bad practice.

Folks,  I don't need to explain to you guys who to write code properly!



Do you understand what beta release means? NXT just made first beta release with released source code. You are clearly the worlds best java programmer (no offense jean-luc) and due to your fluency in all things java you are able to see logic flaws much clearer than C programmers like me.

Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.

Prove me wrong. Prove that you are able to actually find flaws. That is what this thread is about. Notice how in spite of your almost total uselessness to this thread, you haven't been banned. Most people haven't even ignored you based on the hope that you will use your talents to help. If NXT is the sum of all people who contribute to NXT and you contribute too, how is that a ponzi scheme?

Isn't a ponzi scheme something that has no intrinsic value. Are you saying that NXT has no intrinsic value? Are you saying that NXT doesn't work at all? Are you saying that a refactoring can't fix critical problems that you haven't even identified yet?

What exactly are the flaws in NXT logic. Treat it as a whitepaper not a final release by perfect software engineering team staffed by clones of yourself. NXT is in BETA TEST. Not very smart to criticize things that are accepted during beta tests. I thought you were a smart guy, maybe that makes me stupid?

James


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 09:55:19 PM
All of those synchronized(this) can be replaced with AtomicInteger.addAndGet

There was a lot of code that looked like:

synchronized (account) {
   1. Check balance
   2. Do something
   3. Adjust balance
}

Is it safe to get rid of synchronized in the quoted code?

I was specifically referring to code like this:

Code:
synchronized (this) {
    this.balance += amount;
}

If you just need to check the balance and conditionally update it, you can use compareAndSet.

For anything more complicated, you're better off sticking with synchronized.


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 10:02:57 PM
All of those synchronized(this) can be replaced with AtomicInteger.addAndGet
How about this:
Code:
            synchronized (this) {
                this.balance += amount;
                this.unconfirmedBalance += amount;
            }
Each of them being Atomic by itself will not ensure balance and unconfirmedBalance are both updated atomically, a thread could still see balance incremented but unconfirmedBalance not yet updated.


It depends. You're correct that a thread could see balance updated and unconfirmedBalance not updated. But, that exists in the code that was released since there are places where balance and unconfirmedBalance are read outside of locks on the account, e.g.:

Code:
						if (accumulatedAmount + amount <= accounts.get(sender).balance && transaction.validateAttachment()) {

accumulatedAmounts.put(sender, accumulatedAmount + amount);

newTransactions.put(transaction.getId(), transaction);
payloadLength += transactionLength;

}

If you need to ensure they are always consistent, you need to lock around all the reads and writes.


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 05, 2014, 10:06:26 PM
FWIW, it's kind of annoying to be reviewing outdated code while the developers are working on a much newer copy. I understand why an older snapshot has been released, but it is still annoying to keep finding things that have already been fixed :/. But, I guess it's good that the working code is in a better state than the released code.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 05, 2014, 10:09:13 PM
Code:
						if (accumulatedAmount + amount <= accounts.get(sender).balance && transaction.validateAttachment()) {

accumulatedAmounts.put(sender, accumulatedAmount + amount);

newTransactions.put(transaction.getId(), transaction);
payloadLength += transactionLength;

}

Outcome of this code is validated by the peers. Usage of synchronized here would be an overkill in a system with eventual consistency...


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 10:11:58 PM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea. 

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 10:20:15 PM
If you need to ensure they are always consistent, you need to lock around all the reads and writes.
I know, I have done that. All direct reads of Account.balance are replaced with getBalance() which is synchronized. Account.balance is now private (doesn't make a difference now when in the same class, but it will be moved out of Nxt.java one day).


Title: Re: Nxt source code analysis (QA)
Post by: Jean-Luc on January 05, 2014, 10:27:31 PM
FWIW, it's kind of annoying to be reviewing outdated code while the developers are working on a much newer copy. I understand why an older snapshot has been released, but it is still annoying to keep finding things that have already been fixed :/. But, I guess it's good that the working code is in a better state than the released code.
Thanks for your reviews, it could be that you find things I haven't thought of yet. In fact you did in a previous post, now I have added extra checks for Transaction.amount and Transaction.fee in a place where it could overflow. The code is not that outdated actually, it is as of Dec 25 when I first got access to it and we were running it until about Jan 01.


Title: Re: Nxt source code analysis (QA)
Post by: utopianfuture on January 05, 2014, 10:35:32 PM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea.  

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?

LOL at your naive sense of how to build a successful business. Even if you can replicate even a technically better version of NXT in 6 months, the best you can do is to create something akin to Quark or Doge compared to Bitcoin. Even that would be unlikely with current situation. Every decent coder could replicate Twitter in a week still Twitter is worth billion of $ with none of competitor in that space.
In 6 months, I couldn't care less that NXT's codes are 100 percent open. Imitation is the best praise someone said.


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 10:39:36 PM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea. 

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?

You already said you were going to copy NXT and call it NGC. That is the reason you are here, hoping to find some tidbits that will help your NXT clone.

Good luck with rebooting NXT as when everything is fixed and mature it will have LTC marketcap, while your new coin will have you and your followers.

If you are not going to contribute when you can, then lurk, steal and clone NXT. Whatever. I was hoping you had some pride in your skills. I guess if you don't have skills you can't have pride in them.

Good luck with your plan, if you are going to post, please try to post an actual bug however trivial. Please show some respect to those of us who are trying to improve NXT. I somehow get the feeling that you are able to, but choose not to as you view NXT as competition to your own clone. Why not join the original instead of trying to clone?

James


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 10:47:35 PM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea. 

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?

You already said you were going to copy NXT and call it NGC. That is the reason you are here, hoping to find some tidbits that will help your NXT clone.

Not a copy,  a better version.

As it is NXT holders a losing money left and right.  Wallets getting hacked, DGEX not returning coins, negative balances etc.   

 


Title: Re: Nxt source code analysis (QA)
Post by: MrBTC on January 05, 2014, 10:48:59 PM
wow this is very interesting.
thanks for sharing,keep updating guys.


Title: Re: Nxt source code analysis (QA)
Post by: salsacz on January 05, 2014, 11:06:23 PM
at least we finally know who is that troll panama01 from nextcoin forum


Title: Re: Nxt source code analysis (QA)
Post by: jl777 on January 05, 2014, 11:23:26 PM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea. 

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?

You already said you were going to copy NXT and call it NGC. That is the reason you are here, hoping to find some tidbits that will help your NXT clone.

Not a copy,  a better version.

As it is NXT holders a losing money left and right.  Wallets getting hacked, DGEX not returning coins, negative balances etc.   

 

OK, so you admit you are here just trying to figure out how to make a NXT copycat and have no intention of helping. Thanks for confirming my hunch. I am not sure what the right name for someone like you is. I won't miss anything valuable by ignoring you.

You do know the next generation enterprise got totally destroyed. May the force be with you.

James


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 05, 2014, 11:46:12 PM

OK, so you admit you are here just trying to figure out how to make a NXT copycat and have no intention of helping. Thanks for confirming my hunch. I am not sure what the right name for someone like you is. I won't miss anything valuable by ignoring you.

You do know the next generation enterprise got totally destroyed. May the force be with you.

James

Absolutely nothing wrong with a copy, if you can improve on the original.

However,  I am not even sure that there's anything worth copying here.

I haven't seen the spec.  and have no idea that it even works.


Title: Re: Nxt source code analysis (QA)
Post by: Meizirkki on January 06, 2014, 01:01:18 AM
Folks,  I don't need to explain to you guys who to write code properly!
Yea, please don't. GTFO.


Title: Re: Nxt source code analysis (QA)
Post by: User705 on January 06, 2014, 01:25:33 AM


Why not show off how smart you really are, just post some actual logic errors that lead to people losing money? My guess is that you tried to and couldn't find any, so you decided to make a copy of it and call it NGC.


That indeed is an interesting idea. 

So I wait till every gets fixed and mature.

Then I reboot NXT.

How do you like that plan?

You already said you were going to copy NXT and call it NGC. That is the reason you are here, hoping to find some tidbits that will help your NXT clone.

Not a copy,  a better version.

As it is NXT holders a losing money left and right.  Wallets getting hacked, DGEX not returning coins, negative balances etc.   

 
What does picking a weak password or someone not returning coins have to do with bad coding?  I guess bitcoin sucks too since so many bitcoins were never returned and so many wallets keep getting hacked even now five years after bitcoin launch.


Title: Re: Nxt source code analysis (QA)
Post by: User705 on January 06, 2014, 01:52:09 AM
Only a few GPUs.  Let's do a practical test.  Post or PM the instructions.  How many long should the attempt be?  Hours, days?  If it works then you'll have succeeded in proving Nxt to be worthless.


Title: Re: Nxt source code analysis (QA)
Post by: User705 on January 06, 2014, 02:10:46 AM
Only a few GPUs.  Let's do a practical test.  Post or PM the instructions.  How many long should the attempt be?  Hours, days?  If it works then you'll have succeeded in proving Nxt to be worthless.

Consult the tables at:  http://hashcat.net/oclhashcat/


I'm not that technical.  I'll throw 1 rig of 7950s at it for a day or two if you provide instructions.


Title: Re: Nxt source code analysis (QA)
Post by: msin on January 06, 2014, 05:02:01 AM

OK, so you admit you are here just trying to figure out how to make a NXT copycat and have no intention of helping. Thanks for confirming my hunch. I am not sure what the right name for someone like you is. I won't miss anything valuable by ignoring you.

You do know the next generation enterprise got totally destroyed. May the force be with you.

James

Absolutely nothing wrong with a copy, if you can improve on the original.

However,  I am not even sure that there's anything worth copying here.

I haven't seen the spec.  and have no idea that it even works.

Why not become a contributor?  I know you have your reasons, and have to dedicate time on your own project, but you seem to know your Java well and I'm sure the group can get you a sizable bounty of Nxt for your input.  Perhaps help to fund your new project.


Title: Re: Nxt source code analysis (QA)
Post by: ferment on January 06, 2014, 12:19:49 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.

Actually he's only demonstrated opinions on programming style and code structure. We haven't seen him present any code or analyze any specific line of code from the released source with meaningful critique. He's only demonstrated that he's read a couple of books or blog articles on code style.

Code speaks louder than words.


Title: Re: Nxt source code analysis (QA)
Post by: lwilliams777 on January 06, 2014, 06:07:47 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.

Actually he's only demonstrated opinions on programming style and code structure. We haven't seen him present any code or analyze any specific line of code from the released source with meaningful critique. He's only demonstrated that he's read a couple of books or blog articles on code style.

Code speaks louder than words.


+1


Title: Thread: Main
Post by: ZeroTheGreat on January 06, 2014, 07:17:02 PM
I am not sure what the right name for someone like you is.
A pocket troll.


Title: Re: Nxt source code analysis (QA)
Post by: salsacz on January 06, 2014, 09:19:04 PM
gaining transaction fee - Nxt mining - is on the line 6315+? :)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 06, 2014, 09:23:26 PM
gaining transaction fee - Nxt mining - is on the line 6315+? :)

No


Title: Re: Nxt source code analysis (QA)
Post by: salsacz on January 06, 2014, 09:33:26 PM
if it's called "getBlock", then it's on 5137, but I don't know how you call mining there :D


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 06, 2014, 09:39:52 PM
if it's called "getBlock", then it's on 5137, but I don't know how you call mining there :D

generateBlock


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 07, 2014, 12:04:50 AM
There is also the potential for integer overflow in places like this:
Code:
			for (Map.Entry<Long, Transaction> transactionEntry : newTransactions.entrySet()) {

Transaction transaction = transactionEntry.getValue();
block.totalAmount += transaction.amount;
block.totalFee += transaction.fee;
block.payloadLength += transaction.getBytes().length;
block.transactions[i++] = transactionEntry.getKey();

}

Although I don't think it's exploitable. It looks like you're only using totalAmount and totalFee as checksums.


Title: Re: Nxt source code analysis (QA)
Post by: liyi3c on January 07, 2014, 02:56:56 PM
can anyone tell me what's the referencedTransaction used for? I just found it is used as conditions checking somewhere


Title: Re: Nxt source code analysis (QA)
Post by: BloodyRookie on January 07, 2014, 03:25:24 PM
One transaction may depend on another. So if Transaction T1 references Transaction T2 then T1 will not be confirmed until T2 is confirmed.


Title: Re: Nxt source code analysis (QA)
Post by: mczarnek on January 08, 2014, 01:05:52 AM
You guys can ignore FrictionlessCoin.. he's just trying to bring down the price so he can buy in cheaper :)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 08, 2014, 06:59:13 AM
You guys can ignore FrictionlessCoin.. he's just trying to bring down the price so he can buy in cheaper :)

He is funny. I even unignored him again.


Title: Re: Nxt source code analysis (QA)
Post by: delulo on January 08, 2014, 10:42:28 AM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Why would I contribute to what obviously looks like a Ponzi scheme?

You all first explain to me why this entire shenanigan is any different from a Ponzi scheme?

You are asking a lot of question here Frictionless. Maybe you can just answer on question yourself: Why are you spending so much time on bashing this?? Look at the frequency of your posts. And it's not only this thread. I would say 85% of the criticism on nxt comes from you. You are doing this all day!! Normally PR agencies are hired for such things...
Are you just taking personal satisfaction from from bringing other people's productive work down because you are (obviously) not very profound it doing productive things and have time for it because you are lying around at home unemployed (consider the amount of time you put in here). Or are you a professional trying to bring the price down to buy in cheap? I can not think of any other intention that would make sense. It certainly doesn't stem from worries about the code itself. Someone worried about the art of the code or people would not put his critique forward in such a hating and destructive manner!


Title: Re: Nxt source code analysis (QA)
Post by: msin on January 08, 2014, 04:14:05 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Why would I contribute to what obviously looks like a Ponzi scheme?

You all first explain to me why this entire shenanigan is any different from a Ponzi scheme?

You are asking a lot of question here Frictionless. Maybe you can just answer on question yourself: Why are you spending so much time on bashing this?? Look at the frequency of your posts. And it's not only this thread. I would say 85% of the criticism on nxt comes from you. You are doing this all day!! Normally PR agencies are hired for such things...
Are you just taking personal satisfaction from from bringing other people's productive work down because you are (obviously) not very profound it doing productive things and have time for it because you are lying around at home unemployed (consider the amount of time you put in here). Or are you a professional trying to bring the price down to buy in cheap? I can not think of any other intention that would make sense. It certainly doesn't stem from worries about the code itself. Someone worried about the art of the code or people would not put his critique forward in such a hating and destructive manner!

I actually think some of his posts were productive in the sense that he was pointing out bugs.  He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.  He could certainly profit from his observations and help the forum dev team here.


Title: Re: Nxt source code analysis (QA)
Post by: delulo on January 08, 2014, 04:24:27 PM
@Frictionless.  I see that you know what you're talking about with regard to programming.  In fact, you may very well be a brilliant programmer, but the problem is, no one cares.  Why?  Because you have taken it upon yourself as a right to criticize but have not contributed anything productive.  You haven't earned that right yet.  In order to earn the right to be heard you should contribute, even in small amount, not with criticism, but with real productive help.  Once you do that then you've earned the right to criticize and others will actually listen to you.  As it stands, people just think you are a jerk, and using Simon Crowell, a known jerk, as an example doesn't help your cause.  Simon Crowell may be rich and be a star power broker, but I believe he has very few "real" deep long lasting friendships, if any.  

You have not gone about this in an effective way.  If you had played this right you would have contributed in a huge way and others would have sung your praises and others would have gladly signed up for your next generation plan.  In fact they would have become your best sales people and you would have had more folks sign up to help with your development and vision.  But as it stands there are only a few willing to help you and your chances of developing a great system are slim to none.



Why would I contribute to what obviously looks like a Ponzi scheme?

You all first explain to me why this entire shenanigan is any different from a Ponzi scheme?

You are asking a lot of question here Frictionless. Maybe you can just answer on question yourself: Why are you spending so much time on bashing this?? Look at the frequency of your posts. And it's not only this thread. I would say 85% of the criticism on nxt comes from you. You are doing this all day!! Normally PR agencies are hired for such things...
Are you just taking personal satisfaction from from bringing other people's productive work down because you are (obviously) not very profound it doing productive things and have time for it because you are lying around at home unemployed (consider the amount of time you put in here). Or are you a professional trying to bring the price down to buy in cheap? I can not think of any other intention that would make sense. It certainly doesn't stem from worries about the code itself. Someone worried about the art of the code or people would not put his critique forward in such a hating and destructive manner!

I actually think some of his posts were productive in the sense that he was pointing out bugs.  He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.  He could certainly profit from his observations and help the forum dev team here.

Sure. Agree. Open Arm for everyone :)
I was just wondering about the way and the extend one person presented criticism...


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 08, 2014, 04:25:41 PM
He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.
I see he have knowledge in Java, but do not see any proof that it is strong.
He doesn't found any actual problem except well-known "one big file", "no unit tests", "empty catch blocks", "we all will die".


Title: Re: Nxt source code analysis (QA)
Post by: ferment on January 08, 2014, 05:06:31 PM
I actually think some of his posts were productive in the sense that he was pointing out bugs.  He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.  He could certainly profit from his observations and help the forum dev team here.

He hasn't actually pointed out a single bug. All he has done is expressed opinions on code style and software project management. It's trolling.

Those of us who do real world software dev know that the issues that he brings up are stylistic "nice to haves" and can be fixed in a few days of refactoring. No big deal. Code structure, documentation, specs, tests, etc, etc are secondary to a working, innovative system.

Instead, we're focused on 3 types of problems:

1. Immediate/critical bugs causing improper functioning.
2. Attack vectors.
3. Logic flaws - injected or otherwise.

Given the track record of the core dev team (BCNext, C-f-b, Jean-Luc), none of his complaints bother me at all. I have some minor suggestions on process (like how to leverage my 100 nodes for testing), but I'm ok with how things are going given Jean-Luc's release tempo.

Everything in this thread and related ones have me extremely bullish on NXT.


Title: Re: Nxt source code analysis (QA)
Post by: msin on January 08, 2014, 06:03:03 PM
I actually think some of his posts were productive in the sense that he was pointing out bugs.  He definitely has an agenda and strong knowledge of Java, I think we could give him a collective group hug and try to bring him on board with Nxt.  He could certainly profit from his observations and help the forum dev team here.

He hasn't actually pointed out a single bug. All he has done is expressed opinions on code style and software project management. It's trolling.

Those of us who do real world software dev know that the issues that he brings up are stylistic "nice to haves" and can be fixed in a few days of refactoring. No big deal. Code structure, documentation, specs, tests, etc, etc are secondary to a working, innovative system.

Instead, we're focused on 3 types of problems:

1. Immediate/critical bugs causing improper functioning.
2. Attack vectors.
3. Logic flaws - injected or otherwise.

Given the track record of the core dev team (BCNext, C-f-b, Jean-Luc), none of his complaints bother me at all. I have some minor suggestions on process (like how to leverage my 100 nodes for testing), but I'm ok with how things are going given Jean-Luc's release tempo.

Everything in this thread and related ones have me extremely bullish on NXT.

Your work and the work of others here has me very bullish on Nxt as well! 


Title: Re: Nxt source code analysis (QA)
Post by: bitcoinpaul on January 10, 2014, 11:09:24 AM
No more analysis, only flaw crawler? ;)


Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 10, 2014, 04:10:32 PM
No more analysis, only flaw crawler? ;)
1. Most of discussions are there, on flaw reporting thread. "We need to go deeper" :)
2. It's hard to do QA for code, that is known to move forward already. Jean-Luc restrained my ardour on the very first page :)
3. If I find something to analyse I will write post :)


Title: Re: Nxt source code analysis (QA)
Post by: Jaguar0625 on January 11, 2014, 04:55:51 PM
No more analysis, only flaw crawler? ;)
1. Most of discussions are there, on flaw reporting thread. "We need to go deeper" :)
2. It's hard to do QA for code, that is known to move forward already. Jean-Luc restrained my ardour on the very first page :)
3. If I find something to analyse I will write post :)

Agreed. We kept finding things here that were either (1) already fixed or (2) already known as todo items.


Title: Re: Nxt source code analysis (QA)
Post by: jubalix on January 13, 2014, 11:13:57 AM
i'm a little confused why would you need a spec if you have the code and can code with proficiency, you should be able to read through it in about a week or 2 and figure it out?



Title: Re: Nxt source code analysis (QA)
Post by: ImmortAlex on January 13, 2014, 05:44:37 PM
One small late night thought...

The User class hold secretPhrase. Every time when we need public or private key, Crypto is used (actually, it is Curve25519.keygen() on SHA-256 hash of secretPassphrase).

As software developer I personally dislike that result of keypair generation is not cached, so recalculated every time. We talk a lot about how PoS is power saving, and than do math (not very simple math!) again and again, and create the job for GC again and again.

And as user I dislike that my passphrase is stayed in memory. Yes, in terms of Nxt security there's no difference what to steal - my passphrase or my private key. But... being cyborg I can invent new password for every service I use. Those of you who are humans use common patterns often. So thief accessing memory of you device can not only steal your coins, but use your password to steal your FB account for example.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 20, 2014, 12:18:11 PM
Seeking Additional Java Developers

We have successfully decompiled the Nxt source and are now in the process of performing a massive refactoring and cleanup of the code base.

Short term goals.

Remove the primitive addressing scheme and use a scheme that looks like Bitcoin.  Bitcoin addresses are more readable, have a checksum and have many tools to generate them.  Nxt addresses that are all numerical are something that came out of the 1950's.

Secure Wallet.  Nxt wallet is fundamentally insecure.  Exposing a wallet to the public internet for everyone to hack is just idiotic.   No wonder so many Nxt users have lost money!

Nxt does not use an internal database like every other alt coin.  This is idiotic because NXT nodes easily fail and run out of memory.  Furthermore, if you accidentally turn off your node... your wallet can get corrupted!

NEX strives not only to be a fairer distributed Nxt variant,  but a technologically super version.

Join the enterprise... participate with your coding skills!!!

We will not ship SHIT like the Nxt folks.  We will ship product that will secure our users coins!

May I join?

Time to join the winning team!

We have the latest 0.5.9 code for your review!   None of this old garbage, 0.4.7 code that is not relevant!


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 20, 2014, 12:19:28 PM
Seeking Additional Java Developers

We have successfully decompiled the Nxt source and are now in the process of performing a massive refactoring and cleanup of the code base.

Short term goals.

Remove the primitive addressing scheme and use a scheme that looks like Bitcoin.  Bitcoin addresses are more readable, have a checksum and have many tools to generate them.  Nxt addresses that are all numerical are something that came out of the 1950's.

Secure Wallet.  Nxt wallet is fundamentally insecure.  Exposing a wallet to the public internet for everyone to hack is just idiotic.   No wonder so many Nxt users have lost money!

Nxt does not use an internal database like every other alt coin.  This is idiotic because NXT nodes easily fail and run out of memory.  Furthermore, if you accidentally turn off your node... your wallet can get corrupted!

NEX strives not only to be a fairer distributed Nxt variant,  but a technologically super version.

Join the enterprise... participate with your coding skills!!!

We will not ship SHIT like the Nxt folks.  We will ship product that will secure our users coins!

May I join?

Time to join the winning team!

We have the latest 0.5.9 code for your review!   None of this old garbage, 0.4.7 code that is not relevant!


Oh, we shouldn't rely on 0.5.9, it has unimplemented features. Without this features ur coin won't fly.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 20, 2014, 12:19:51 PM
One small late night thought...

The User class hold secretPhrase. Every time when we need public or private key, Crypto is used (actually, it is Curve25519.keygen() on SHA-256 hash of secretPassphrase).

As software developer I personally dislike that result of keypair generation is not cached, so recalculated every time. We talk a lot about how PoS is power saving, and than do math (not very simple math!) again and again, and create the job for GC again and again.

And as user I dislike that my passphrase is stayed in memory. Yes, in terms of Nxt security there's no difference what to steal - my passphrase or my private key. But... being cyborg I can invent new password for every service I use. Those of you who are humans use common patterns often. So thief accessing memory of you device can not only steal your coins, but use your password to steal your FB account for example.

NEX is working to fix this problem.  Head over and please contribute your development talents to a "Fair and Honest" coin.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 20, 2014, 12:20:44 PM
Seeking Additional Java Developers

We have successfully decompiled the Nxt source and are now in the process of performing a massive refactoring and cleanup of the code base.

Short term goals.

Remove the primitive addressing scheme and use a scheme that looks like Bitcoin.  Bitcoin addresses are more readable, have a checksum and have many tools to generate them.  Nxt addresses that are all numerical are something that came out of the 1950's.

Secure Wallet.  Nxt wallet is fundamentally insecure.  Exposing a wallet to the public internet for everyone to hack is just idiotic.   No wonder so many Nxt users have lost money!

Nxt does not use an internal database like every other alt coin.  This is idiotic because NXT nodes easily fail and run out of memory.  Furthermore, if you accidentally turn off your node... your wallet can get corrupted!

NEX strives not only to be a fairer distributed Nxt variant,  but a technologically super version.

Join the enterprise... participate with your coding skills!!!

We will not ship SHIT like the Nxt folks.  We will ship product that will secure our users coins!

May I join?

Time to join the winning team!

We have the latest 0.5.9 code for your review!   None of this old garbage, 0.4.7 code that is not relevant!


Oh, we shouldn't rely on 0.5.9, it has unimplemented features. Without this features ur coin won't fly.

Our code base is decompiled off the latest 0.5.9 release,  so it has every feature that Nxt has ever implemented.

Also,  we don't care anymore if you release any new feature, because we are refactoring of of it for to create a more secure and fair platform.

Nxt is going to be ancient technology pretty soon with its PROPRIETARY SOURCE CODE.


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 20, 2014, 12:22:01 PM
Our code base is decompiled off the latest 0.5.9 release,  so it has every feature that Nxt has ever implemented.

Why do u want me to submit the code then?  ???


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 20, 2014, 12:25:21 PM
Our code base is decompiled off the latest 0.5.9 release,  so it has every feature that Nxt has ever implemented.

Why do u want me to submit the code then?  ???

To save us the trouble of validating our decompilation.

If you don't want to submit source code,  then say so for the record.

We are giving you this last opportunity to save face to the world.

(our next steps is to run one last validation step and then we fork forever)


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 20, 2014, 12:26:24 PM
Our code base is decompiled off the latest 0.5.9 release,  so it has every feature that Nxt has ever implemented.

Why do u want me to submit the code then?  ???

To save us the trouble of validating our decompilation.

If you don't want to submit source code,  then say so for the record.

We are giving you this last opportunity to save face to the world.

(our next steps is to run one last validation step and then we fork forever)

Well, u have to wait for a while if u want to get a code without flaws.


Title: Re: Nxt source code analysis (QA)
Post by: FrictionlessCoin on January 22, 2014, 11:05:15 AM
Nxt code is extremely vulnerable.

We therefore decided to remove source code 5.9 that we decompiled (and got working) from our repository.

Fix your code.

NXT tip jar:  1552250839866495550


Title: Re: Nxt source code analysis (QA)
Post by: Come-from-Beyond on January 22, 2014, 12:11:38 PM
Nxt code is extremely vulnerable.

We therefore decided to remove source code 5.9 that we decompiled (and got working) from our repository.

Fix your code.

NXT tip jar:  1552250839866495550

U r allowed to return the source code back online.


Title: Re: Nxt source code analysis (QA)
Post by: jubalix on January 24, 2014, 12:16:31 AM
can you put a link to the solutions as well as crossing them out.