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