Topic: NXT :: descendant of Bitcoin - Updated Information - page 1936. (Read 2761645 times)

I am very good at creative solutions to so called impossible problems. I have extensive software expertise. I am trying to make nxt the most secure crypto at the architectural level. I am not proposing any new cryptographic algorithms, just using standard public private key in a way that has not been done before

Maybe i am totally offbase on this, but until i get a clear explantion about how this is wrong, i am apt to believe it is possible to add second layer of security to nxt

Why do you want me to stop?

James

I doubt that if someone logs with "1234" password they will use a strong 2nd password.

Just quoting and bolding this so it doesn't get lost, particularly after the rogue client affair. Thanks for the update, Captain.

is there any time (time zone) for the source release?
I need to be sure the drinks will have the right temperature ;-)

Why we should move our coins to new accounts while  i have not used my pass on other public nodes and only i my local node?

I don;t think he is trying to be one.

so please, don't try to be one.

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

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!

You better use the real hashtab:

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

What stops attacker from doing exactly the same thing?

Drexme needs to pay some bills: https://bitcointalksearch.org/topic/m.4264260 and he is right - 35k Nxt = 3 Bitcoins stolen from the giveaway fund

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

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.

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

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

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

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

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.

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