2@Gracchus you're welcome! I guess they used Curve instead of Ed because they couldn't find a suitable Ed implementation for Java. I guess (don't want to look at the code anymore! it's awful) they're just computing signature = shared_secret(32_byte_private_key, generate_public_key(32_byte_hash(data))), but I don't really have the theoretical knowledge to understand the drawbacks. – kaoD – 2014-01-15T02:48:13.707

2

@Gracchus notice the [7:0] (Pythonic syntax) or just line 4973. They hash the first eight bytes of your public key (in reverse order) which gives us 256^8 = (2^8)^8 = 2^64 combinations. This means each account has 2^256/2^64 = 2^192 suitable public keys!

2@Gracchus Bitcoin "suffers" the same fate since it maps 2^256 public keys to 2^160 addresses (2^96 keys per address), but 2^192 public keys per address is just awful! And only 2^64 accounts is even worse. I guess they just wanted short accounts, but they're never going to fix that without breaking their current accounts. – kaoD – 2014-01-15T02:56:58.847

When I first saw Nxt, I thought its concept of pure PoS was intriguing, and its approach of "new code from scratch, in Java" was fresh air. Didn't give a thought about their addresses, I now see I should've. But, what else is wrong with NXT that you say the high collission probability "is the least of their problems"??? – Joe Pineda – 2014-04-02T14:43:56.273

@Gracchus: user12480's answer clarifies the situation; it's apparently not as bad as you were thinking. – Nate Eldredge – 2014-04-03T00:48:30.293

I'm not sure I understand. Are you saying that in order to spend coins, your key has to not only have the right hash bits, but also to match a previously announced key? Could you point to the part of the code where this is enforced? – Nate Eldredge – 2014-04-02T06:01:41.437

Step 1: User chooses a Password. Must have a strong 128 bit entropy, or clients should generate it (the newer clients do, must safer for newbies). PrivateKey (256 bits) = Hash (Password) -- PublicKey (256 bits) = Curve25519 (private key) -- Account ID == first 64 bits Hash (Public key) --

You can send Nxt to that new account, but the network doesn't yet know the public key of that account. Once you send outgoing transaction from that account, your public key is known and you control that account with a 256-bit public key. – user12480 – 2014-04-02T23:27:40.907

1If there is collision with another password that results in the same account number, they cannot steal money, as your public key is permanently linked to the account once there is outgoing transaction. The client should warn the second user if it happens.

The account ID can be changed to 80 bits once this becomes a problem, but I doubt it's a problem right now with only 30,000 accounts. – user12480 – 2014-04-02T23:34:26.420

1Ok, that helps. But suppose I want to receive some coins. I generate a brand new account, give the account number N to the sender, and she sends the coins. Now isn't there a window for Mallory to find another private key for which the account number is also N? If Mallory finds such a key before I make an outgoing transaction from my new account (and I might wait indefinitely to do so), he can spend them first. Do I have that right? – Nate Eldredge – 2014-04-02T23:45:18.487

Yes, there is a "window" but it would be a very small window. 64-bits isn't easy to crack (even 4 billion tries per second would take 50 years an average). All you have to do is transfer 1 nxt to the new account, do something, like create an "alias" for that account (useful thing to do anyway, as people can use the alias instead of account ID to send money), and that will propagate your public key to the blockchain – user12480 – 2014-04-03T00:04:43.357

2I see. But I do have to remember to do that. If I didn't plan on spending those coins, and left them in the fresh account for years and years without making another transaction or propagating the public key in any way, I could start to be vulnerable. If the amount were very large, an attacker could be motivated. – Nate Eldredge – 2014-04-03T00:46:58.583

This got discussed in this thread https://bitcointalk.org/index.php?topic=366105.0 For what I understood, a freshly created NXT account is indeed vulnerable to hijacking (empty or with coins) until such account "sends" some coins to somewhere else - from that point on, the public key gets associated with the 20 digits address, and no other can use it. An account which received thousands of NXT whence no coin has ever exited, though, would be very vulnerable. I guess the most secure method is: open an account, receive 1 NXT from the faucet, send back such coin to the faucet - now you're secure.

That also means that you can't have cold storage, right ? See http://bitcoin.stackexchange.com/questions/24517/is-it-possible-to-have-complete-cold-storage-in-nxt