Relax, I am also using IntelliJ. And the above has been fixed in 0.4.9e.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have posted the NRS source at:

https://bitbucket.org/JeanLucPicard/nxt-public

This is version 0.4.7e, as provided by BCNext, without any modifications by me.

The Alias System is not included in the source, as it is an advanced feature.

The Transparent Forging is also not included, as it was released in 0.4.8 only.
Therefore, clients compiled from this source will only be able to reach up to
block 30000 on the current blockchain.

All my memory leak fixes and performance optimizations that went into 0.4.8
and 0.4.9e are also not included.

For reference only, the downloads section contains the compiled 0.4.7e binary
package as originally released. The json-simple and jetty libraries in it will
be needed to be able to compile the Nxt.java source. As explained above, this
binary package is out of date and will not work against the current blockchain
beyond block 30000.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJSxqPVAAoJEFOhyXc7+e2AkdQP/3xl8Wkm9gD3vvIgckisPGRM
gUcMZh0ThhzZgGs6SQhz1by8f79Jczz32/6UdFgY9BES1Vrow3ccmBzMjSR3B2gO
lMY49vD0P1r6iBN4nau3Fsite8rQh7r0MS/d3kqaosa3BFe6f3oqCeYNQtrKrQlw
dGUs8u+oCN6Lea6Lu4yJCouwSEH89Bybs9PzPZJoLdR4/X+IEN3RzJnQyB+0LLJM
KaVyjal7EN4DRyzeRkRKh3qxGC4YPAOCh0+8aacDByXuquhzANO2JyoSPuifx9m5
aBXsSW0PxA4yoMEXl5DxWwVfe77xRxfdkLby7BDHVjKOJPLP/66RwkEunsAvqrfR
buZR+BM+A/7nBwcaDi35VNDRm0mt+uWFAunknCVucITu1Q0KGFPlNtfs5vfxXwCY
AxSFrLgNtik1bE4LVtp8KJ6OHt/S+T2CggSglIDp9CAI/zhL98MgeWhhKavni1Y0
QhLY3EOM9oCLF68lm/dq2CEd5I8Z+U+wL7lHNKXM7cMMfkiKrZ5o98usFUPEsxTj
nWXbM7e90BJEtA+R3fuZEdAlVJ5r71l9sdTWewQ6TuBjGgjFeLVOZ19ItPU9S/bB
bevzwYtme/x5cRZECZU0sIxHMEp3hJIJhG9l37HNYq4oF+esGrAra0IYXr+q6PAr
gch7Ndk9LSnKiXMqo8Ph
=HtaM
-----END PGP SIGNATURE-----

Do you keep the log with those exceptions? Please post it here or send it to me.

What version were you running?

Were you logged in at one account only at the time, or had several browser windows open? Were any other account mining in the background (if you closed their tabs without clicking the unlock icon first)? Any other relevant detail?

Checksums will not help with this type of bug. Very likely the account to which the transaction was wrongly sent will also have passed the checksum.

If it does a secure erase, overwriting the file with random bytes, yes, in theory. Except for solid state drives you never know if what you are overwriting is really the original file location, because of the wear-leveling and remapping magic they do internally.

0.4.9e should be more stable and with better performance and memory usage than 0.4.8. I labelled it experimental because I made a lot of code changes. But I haven't changed any business logic.

We don't have unit tests yet, and the way the code is structured it will take some time before we can add automated unit tests for a new release. My servers have been running 0.4.9e and mining with it for two days now, without problems, and in particular I no longer find them stuck on a wrong branch. But for testing transactions, the best I can do is try making a few transactions manually and see if it works.

With 0.4.8 and earlier, URLs containing your secret phrase were being cached by the browser in the disk cache. So yes, you should delete that cache, and if you are ever worried about a situation like your laptop being stolen, confiscated by the authorities, at the US border, and so on, whoever has access to it can examine your hard disk and find that password.

With 0.4.9e, those URLs are not cached on disk, but firefox still keeps them in the memory cache. I haven't tested other browsers. And I don't know how easy it is for other websites to exploit and try to fish out what is in your memory cache. So, to be safe, use a separate browser profile, or incognito mode, when accessing your Nxt node at localhost.
 

Please, do release the source of your vanity generator. I was about to warn people not to use it, because it is a closed source tool posted by a new user with 5 posts only. Can't be too paranoid after the incident we already had. Without the source, how does one know if your random prefix is really random?

I will make sure the link is posted here and also at http://info.nxtcrypto.org. The source code released will be that of 0.4.7e, the last version before Transparent Forging was added.

I think I forgot to mention that in the change log, but now that Transparent Forging is enabled and we are after block 30000, clients older than 0.4.8 will not be able to process blocks after 30000. So everybody please upgrade to 0.4.8 at least. There were a few posts with people claiming to have their servers mining unattended, well, if they are still on 0.4.7e or older they no longer are mining.

Your blocks.nxt file got corrupted because the Java process was killed and didn't manage to save it completely. Next time try Ctrl-C inside the command window instead of just closing it. Or does Ctrl-C even work on windows... no idea, but always works for me on linux.

In 0.4.9e I make sure to wait some extra time (up to 10 seconds) for the background java threads to finish, before saving blocks.nxt and exiting. I would expect this to reduce the chance of corrupted .nxt files, but it also means you have to be patient and give it a chance to exit normally for at least 10 s.

That's normal, you generated an orphan block. This is not a crash and is no reason to restart the client.

I meant 12 noon, it should be afternoon there.

Source will be made public around 12:00 UTC.

Isn't there a javascript library to check sha256 sums? If so, somebody more fluent than me in javascript can easily add an update.html page to the client. It can request the value of the NRSversion alias from localhost, which contains the latest stable version and sha256, and I can also start putting the download url as a value of NRSrelease alias. Then download the zip file from that url, check if sha256 matches, and notify the user whether the downloaded zip file is legitimate or not. No need to trust a third party or manually check sha256 sums. Only the first time you download a client need to verify manually.

Fine, I will start one tomorrow after I do it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Version 0.4.9e is available for download from:

http://info.nxtcrypto.org/nxt-client-0.4.9e.zip

sha256: 4e12df42f9f4727fa34eb62483880c0b2b93f45dfff4b4db8fdc293aecb815e9

- From the blockchain, the alias for the sha256 sum is NRSbetaversion:

https://localhost:7875/nxt?requestType=getAliasURI&alias=nrsbetaversion

This is to be considered EXPERIMENTAL release. There are quite a few changes so be careful. Stay with the stable 0.4.8 version if you don't want to take chances. But our flagship NCC-1701-D has been running 0.4.9e since yesterday without issues.

Change Log:

Many concurrency related fixes and optimization. Those should significantly improve performance and stability and decrease the likelihood of the client being stuck and needing a restart.

Performance optimizations, reducing the number of temporary objects being created in the peer networking, making sure connections are properly closed. Memory requirements are lower now, my servers never exceed 1.5 GB. You should be able to run it on a 2 GB VPS node with -Xmx1536M without problems now. If you don't attract a lot of traffic (don't publish your IP), memory will even stay below 1GB.

Unlocking an account now makes sure to automatically lock out all other instances of the same account on the same server. In other words, if you open several browser windows to the same server (localhost), you can only be logged in to the same account in one of them at a time. This does not prevent you however from unlocking the same account on multiple machines (but you shouldn't be doing that).

Generate authorization token will also ask for a secret phrase confirmation again.

As you may or may have not noticed, Transparent Forging has already started. My last minute decision to start at 32000 somehow didn't make it in the package I released as 0.4.8 (I make mistakes too), so 0.4.8 got released with the switchover still at 30000. So block 30000 it is now, and we are already there.

Minor changes: Added Get Account Aliases, Get Alias URI, and Get Multiple Account Balances features to the https://localhost:7875/admin.html page. Added a few more well-known nodes to the default in the web.xml.

There is one serious security issue which is not completely fixed in 0.4.9e. All requests URLs are being cached by the browser, and even though they don't appear in the browsing history (which is why we didn't discover the problem earlier), they are still in the browser cache. Check for yourself using about:cache on firefox.
This is bad, as it means your secret phrase is being written out to disk as plain text in the browser cache. And I am sure javascript exploits will appear which will try to extract it from there. To really fix that, all API requests from the browser that include the secret phrase have to be sent as POST, rather than GET requests. But this will require some significant changes to the javascript client, which will take some time. As we don't plan to maintain the current javascript client, I am not sure if such rewriting should even be undertaken now. In 0.4.9e I at least added the response headers which prevent caching to disk. Firefox honors those, but still caches the request URLs to memory. To be safe, I strongly suggest using a separate browser profile only for accessing your Nxt client, or private browsing mode. Everybody using 0.4.8 and earlier should immediately delete their browser cache.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJSxUyZAAoJEFOhyXc7+e2AZhAQAKgm5PfGywUCB5AJsMqsxPla
6gPDDU0QrayOqeuEiVyHHj1whaua7MQH7ImpNazGuRRp5dXgm0iiq2pcZkz/m+jY
A970Wxj5wGleJp6GiAb0+7BgwU64DYOnDD4Q2H2IbFjDUdPqdXkgFvkb+jBbUpZO
xGAxCQRcfa3RnjlFjZK5EVqGUSY4ATUWhs0r9bZ4GuiqX/7PZ3Wb7WgT1pCf6g1c
IJqJB8QbIwPj+qtyG7PB1VN9j6QHt/i+Fx8OjdHWxBFQ3FIZWj7F5Bw2ox3Vb6Uw
P8ogvWu00bNZeJV4Qc4PG3tPqUtJOrXSe7CWX7qMMHyD3Y3tcrL4SR+fRKJUoxG6
obHPfyTHuCeGMrHJKSCXAY7jITZguFg4VOo16u+F3SxJ3lMVfbbpfJZ5IZg4du0e
L9Vg2yLZrdDr3qIBsuR41fuIER4+dze5d2w7hhUrPWoAHgSwUc03NdBFfIeMgI9e
UZzU/nnpjsE5zPNZSOe6PjgDTLqWrc1UKQ7m1tmlxMtkpx8/UEvr5JKWLuW7XuDm
mzDcBRlgTULR1WOXOnxFauWf5de+k6Fyq1S/SgyxSsqTqrvRCuK4IpROB06T0g/T
wLBF44hjmgLsZtQFLNWyt80u8npG7QYi+b+QuV+s469+SKJDuU4fVgVZq1/tyAPr
I0MxSJGxoNwV2CVCOvmW
=o9Il
-----END PGP SIGNATURE-----

Yes. But PaulyC was not running a big account with a well-known and hallmarked IP, right?

We should focus on finding out how his account was hacked. It is not likely to be a remote exploitable hole exactly because it was not a big public node. I mine on a machine with a public IP that is on almost all the time with an account of a few million, why wasn't I attacked? I just don't think it is a remote exploit at work here. More likely something in his browser or computer. A javascript cross-site scripting exploit? Was he browsing any other sites at the moment, possibly Nxt - related?

The server (the java process) stores the user secret phrase for as long as your account is unlocked. But there is no API request that you can make to force it to use that phrase for sending money, unless you also send the secret phrase in the request again.

The client (the browser) does not store the secret phrase. Before 0.4.8, when doing send money from the browser, it would identify itself to the server using a random session id generated by javascript. I didn't like that and this is why I removed that possibility and added the requirement for secret phrase on the send money dialog too.

I don't have any idea how this may have happened either. Just wanted to confirm, at the moment the theft happened your client was running and you had the browser window opened, and your account was unlocked (you were seeing your balance and the "send money" arrow), is that all correct?

Just trying to differentiate the possibilities, whether the hacker obtained you password via brute-force or some other way and initiated the transaction from another machine, or somehow your own machine was tricked to initiate the transaction.

And you were running 0.4.8 at the time, right? I added the second check for secret phrase before send money exactly to increase security, so that even if you account is unlocked in the browser you still need to enter your password again.

Another question, did you generate your random-looking password using some software - password manager, online service, or created it manually by typing at random?

You should be, I tested that.
I would be particularly interested in praise feedback about the memory usage of 0.4.8.