NXT :: descendant of Bitcoin - Updated Information

[NxtChoice]

It is very important to have a functioning client. I see that your team is not working on the client side anymore, but could you please coordinate the development of it? Otherwise your server-side codes will be worthless if the users will turn away from Nxt because of the lack of a usable interface.

It's a decentralized system, the community should coordinate itself. I'll do my best to add all API calls that we need for clients, this is the only thing I'm going to do.

Could you please add API for the forging tx? The present API getAccountTransactionIds doesn't return forging tx. Of course, we can write some code to walk through the block chain, for example, ruby code, but it seems too slow. Thanks.

[1713956972]

1713956972

[1713956972]

1713956972

[1713956972]

1713956972

[1713956972]

1713956972

[jl777]

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I think it would be easiest to just make it so that if an account ever sets a sendmoney public key all send money transactions for that acct are encrypted and all nodes can decrypt using public key that is put into a special alias of the form (acct number).(public key)

I think this adds meaningful second layer of security without needed emails, sms
It is decentalized, all nodes can decrypt

Most importantly, even with the current hacked client, if these calls were in place, even a weak private key woild have created a large obstacle to the password thief. Using a high entropy key would make it pointless to even bother trying to decrypt unless the account you stumbled onto had millions of nxt

Please confirm or deny if my approach would have prevented any losses from current password thief

By making it a onetime activation it does mean that if you lose the private key, you woild have to spend all the nxt in the acct buying aliases and generally spending it on services, but this i think would be an acceptable tradeoff

James

[jl777]

Jean-luc

Assuming we had the above two api calls, how hard would it be to add a second layer of security to sendmoney in the client?

I am assuming we will get a handy button to generate a max entropy private key to use, both for nxt acct and second layer key

Another feature for down the road that would be cool is a fragmented wallet. If we can automatically generatea one set of keys, why not 10? Then we can compartmentalize oure nxt holdings to eliminate total loss in case one acct is compromised. A higher level view that just shows the combined totals would make it almost transparent that there are many subwallets. All is is for later, just wanted to get the idea out there while we are in a security conscious mode

James

[GCInc.]

Just catching up for the unfortunate happenings of the past 24 hours with the NXT Client.

Both clients link used recently on nextcoin.org (the MEGA and nxcrypto ones) main thread seem fine, as I had avised the mod replacing Drexme to use only links originating from CfB.

However, the hash checker link that leaded to http://hashtab.ru/ downloads a file that reports backdoor on 1/49 scans on Virustotal:

https://www.virustotal.com/en/file/56d18a52eb728807cb399d606eb5a127962684134b9923d62ed76b87c0d41a8f/analysis/1388661917/

I have not been able to verify whether that is a false positive or not.

Can anyone confirm that hashtab.ru serves a legit version of the hash checker?

[Come-from-Beyond]

Can anyone explain why this transaction : id= 17268617256988246673 didn't go through? http://87.230.14.1/nxt/nxt.cgi?action=2000&tra=17268617256988246673

It was in a block 15077040953933790557 , other transaction in this block worked.
Just this one who don't work. It's not confirmed and i don't see why

It's confirmed.

the account http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=11731960900805566730 don't have the coin

Ah, right. It's confirmed in the BCE only.

[Come-from-Beyond]

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I'll add prepareTransaction that will be signed locally and broadcasted.

[jl777]

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I'll add prepareTransaction that will be signed locally and broadcasted.

Please confirm that this means that i was right when i said that we could add a second layer of security even though nxt is a distributed system. We achieved the impossible, yes?

James

[bidji29]

Can anyone explain why this transaction : id= 17268617256988246673 didn't go through? http://87.230.14.1/nxt/nxt.cgi?action=2000&tra=17268617256988246673

It was in a block 15077040953933790557 , other transaction in this block worked.
Just this one who don't work. It's not confirmed and i don't see why

It's confirmed.

the account http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=11731960900805566730 don't have the coin

Ah, right. It's confirmed in the BCE only.

Any idea how that can happen?
The block was valid. (other transaction in the block worked)
The transaction was not?

[grex]

Just deleted my nxt folder and reinstalled 0.4.8 because of the exploit warning.
Unfortunately my client doesn't get blocks now, I'm stuck at block 0.

How to fix this? Any official/save blockchain download?

E: Deleting everything again and installing 0.4.9e fixed it.

[wesleyh]

My online node can't pass block 30472 - any ideas why? Have deleted blockchain and redownloaded, used different peers, etc..

[Jean-Luc]

-----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-----

[Come-from-Beyond]

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I'll add prepareTransaction that will be signed locally and broadcasted.

Please confirm that this means that i was right when i sais that we could add a second layer of security even though nxt is a distributed system. We achieved the impossible, yes?

James

This won't add the 2nd layer of security. Ur description doesn't make much sense. Could u provide more technical details (algos, workflows)?

[Come-from-Beyond]

Any idea how that can happen?
The block was valid. (other transaction in the block worked)
The transaction was not?

It was in orphaned block and none of public nodes saw it. U should wait till the transaction expires, it may be confirmed eventually.

[davethetrousers]

My online node can't pass block 30472 - any ideas why? Have deleted blockchain and redownloaded, used different peers, etc..

30782	9296180864890406740	2.1.2014 12:40:59
1	500 + 1	128 B
2	15000734117199158573	389 %

Both my pubnodes have it: 109.230.224.65 and raspnxt.hopto.org


@Jean-Luc: Good to see a new version so quickly. Will test it on the RPi, to see if the memory improvements are noticeable again. The prior version has already been a lot easier on the memory, making it more usable on the RPI in particular.

[jl777]

CfB

Will you add the following api calls?
Set sendmoney public key
Encrypted sendmoney

I'll add prepareTransaction that will be signed locally and broadcasted.

Please confirm that this means that i was right when i sais that we could add a second layer of security even though nxt is a distributed system. We achieved the impossible, yes?

James

This won't add the 2nd layer of security. Ur description doesn't make much sense. Could u provide more technical details (algos, workflows)?

I am not a cryptographer and at airport without access to src code, so i can only describe in general terms

I want to be able to make an acct required to encrypt all sendmoney calls. By broadcasting public key via alias type mechanism all nodes will be able to decrypt transactions. Since hacker who stumbled onto nxt acct key wont have send money private key, he cant sendmoney even with nxt acct password

What part doesnt make sense?

James

[salsacz]

Drexme needs to pay some bills: https://bitcointalk.org/index.php?topic=384097.msg4264260#msg4264260 and he is right - 35k Nxt = 3 Bitcoins stolen from the giveaway fund

[Come-from-Beyond]

What part doesnt make sense?

What stops attacker from doing exactly the same thing?

[intel]

Just catching up for the unfortunate happenings of the past 24 hours with the NXT Client.

Both clients link used recently on nextcoin.org (the MEGA and nxcrypto ones) main thread seem fine, as I had avised the mod replacing Drexme to use only links originating from CfB.

However, the hash checker link that leaded to http://hashtab.ru/ downloads a file that reports backdoor on 1/49 scans on Virustotal:

https://www.virustotal.com/en/file/56d18a52eb728807cb399d606eb5a127962684134b9923d62ed76b87c0d41a8f/analysis/1388661917/

I have not been able to verify whether that is a false positive or not.

Can anyone confirm that hashtab.ru serves a legit version of the hash checker?

You better use the real hashtab:

http://www.addictivetips.com/windows-tips/hashtab-calculate-compare-hash-checksum-values-from-file-properties/

[newcn]

In summary,what I found from Chrome history:
from download history, the malware link was:
http://162.243.246.223/nxt-client-0.4.8.zip
sha256: 948ce760c379f13f4ea9def6babaa36b0d706bf91098f1d64945fdde3eac5f06

the creation time and modification time of the zip file on my local disk was:

Code:

creation time:2013‎.‎12‎.‎31‎，‏‎20:31:14
‎modified time:2013‎.‎12‎.‎31，‏‎20:35:16

in that time period, I only accessed two pages:

Code:

20:29 https://bitcointalk.org/index.php?topic=345619.11740
20:30 https://bitcointalk.org/index.php?topic=345619.0

from the download history, I probably downloaded the malware from the first page,that is:
http://info.nxtcrypto.org/nxt-client-0.4.8.zip
(I found the new version and checked it on the first page, and it's true, there's an update there, but I don't like the mega site, its slow from my home, so I downloaded the link from the first page)
the thief might changed the link directly,
 or he might changed IP address of info.nxtcrypto.org
current IP of info.nxtcrypto.org is 46.28.204.121,
which is different from 162.243.246.223

the following are some clues about the accounts where my nxt goes:
2 of my accounts were stolen, one of them lost 18198 nxt, the nxt goes to an account which only has one transaction, the account is 9793828175536096502, the nxt is still in this account, I find nothing from this account.

another account of mine, which had 93 nxt balance, was stolen to an account which have many transactions, I found sth from this account:6164081464868000542, the first transaction to this account happened at 16 DEC, which refers to another acc:496131565008433801, in this account, there're 3 incoming transactions from acc:6635869272840226493, which I remember is the account of dgex, each withdraw at dgex are coming from this account(at least for me), so, if the thief is the owner of acc:6164081464868000542 and acc:496131565008433801, he probably has an id in dgex!

[jl777]

What part doesnt make sense?

What stops attacker from doing exactly the same thing?

That is why i specified that once you do this to an acct, it cannot be changed
This is why it needs protocol level support and not just client side
Like an alias belongs to first acct, sendmoney public key cannot be changed once it is set

People who want to secure their acct could set this up before they put big money into it

How could the hacker set sendmoney public key before the acct is fully funded?

James