5

Nextcoin seems to convert 256-bit Curve25519 256-bit public keys into "account numbers" that have only arabic numbers and seem to only have a length of 20.

How is that done?

Examples

In the Nextcoin forum, users leave their account numbers.

|improve this question
  • References? I'm having a hard time even finding one of those account numbers. – kaoD Jan 14 '14 at 22:14
5

According to these lines an accountId seems to be...

int(sha256(publicKey(sha256(passphrase)))[7:0], 256)

...which translates to 256^8 accounts or roughly 2 * 10^19, which fits the idea of around 20 arabic numerals.

Given there are only 2^64 unique accountId and the birthday paradox, you can check this collision probability table (the 16 bytes/64 bits row). If each person in the world had a single Nextcoin account, the collision probability is greater than 75%! I'm sure this is the least of their problems.

This looks really amateurish. Really amateurish. Really, REALLY, REALLY amateurish. Stay away from this coin!

|improve this answer
  • 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 Jan 15 '14 at 2:48
  • 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! – kaoD Jan 15 '14 at 2:49
  • 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 Jan 15 '14 at 2:56
  • 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 Apr 2 '14 at 14:43
  • @Gracchus: user12480's answer clarifies the situation; it's apparently not as bad as you were thinking. – Nate Eldredge Apr 3 '14 at 0:48
3

Public keys are 256 bits. Account numbers (for brevity) are 64-bits. However, the person who sends first outgoing transaction with that account, controls the account with 256-bit public key.

You cannot take over an account by collision as it's protected by 256-bit public key.

|improve this answer
  • 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 Apr 2 '14 at 6:01
  • 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 Apr 2 '14 at 23:27
  • 1
    If 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 Apr 2 '14 at 23:34
  • 1
    Ok, 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 Apr 2 '14 at 23:45
  • 2
    I 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 Apr 3 '14 at 0:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy