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.

2 Answers2

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!

kaoD
  • 988
  • 6
  • 13
  • 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 02:48
  • 2
    @Gracchus notice the `[7:0]` (Pythonic syntax) or just [line 4973](https://bitbucket.org/JeanLucPicard/nxt-public/src/4073c21098076d3469b3f74d49e73ffabe3a2001/Nxt.java?at=master#cl-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 02: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 02: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 02 '14 at 14:43
  • @Gracchus: user12480's answer clarifies the situation; it's apparently not as bad as you were thinking. – Nate Eldredge Apr 03 '14 at 00: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.

user12480
  • 131
  • 2
  • 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 02 '14 at 06: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 02 '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 02 '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 02 '14 at 23:45
  • 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 Apr 03 '14 at 00:04
  • 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 03 '14 at 00:46
  • The user must have one outgoing transaction (this isn't bitcoin clone, different system, different idea) The newer client warns the user if there is no public key. Try this client running on testNet http://nxtra.org/nxt-client/ it will say "Warning!: Your account does not have a public key .." You can ask for testnxt here: https://nxtforum.org/general-discussion/some-testnxt-to-test-asset-exchange/ – user12480 Apr 03 '14 at 00:58
  • 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. – Joe Pineda Apr 05 '14 at 17:42
  • 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 – CoinsKillTheFed Apr 12 '14 at 03:24