DONT GO POSTING THIS ANYWHERE UNTIL FIRM PEER REVIEW
First I will go over total combinations of all entities, then I'll go over the address violation between them.
Definitions:
Passphrase can be any 100 unicode chars
SHA256(passphrase) gives privateKey of 256 bits
Curve25519(privatekey) gives publicKey of 256 bits
SHA256(publickey) gives accountId of 256 bits
First 64 bits of accountId is 20 digits visibleID (visible in the upper left of the client)
Combinations of different entities:
First, lets talk about passphrases. Its unicode, but lets round down to the 97 characters available on my keyboard, between letters upper and lower, numbers, and symbols. Actually, lets round that up to 100 for ease of future math. So thats 100^100 or 1e+200 or
1000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000
different possible passphrases. In reality this actual number of all possible unicode combinations is vastly vastly vastly larger due to what unicode actually allows, but lets just talk about terms of how we expect the system to be used. IMO, for this mental exercise, it is very sufficient.
The total number of private keys, or total number of SHA256(passphrase) combinations, is 2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000
Total number of public keys, or number of different Curve25519(privatekey) combinations, is same as total number of private keys: 2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000
Total number of accountIds, or number of SHA256(public_key) combinations, is also same as total number of private keys: 2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000
And total number of visibleIds, 2^64 is 1.84467E+19. To try to account for rounding the others down I will round this one up to 2e+19, or or 20000000000000000000
Address violations:
First, with 1e+200 possible passphrases and 1e+77 possible private keys, we have 1e+123 passphrases that can each generate the same private key. For accidental situations, I like these odds, as 1e+77 is waaaaaaaay more than the total number of users to ever use NXT. For cracking though, its another deal. Id have to do further math on the capability of current and future-predicted machines and their ability to crack this.
Second, Im not intimately familiar with the inner workings of sha/curve, so I cannot say for sure if each of the unique 1e+77 privatekeys will generate its own unique publickey for a 1 to 1 correspondance between all privatekeys and publickeys, and if each of the 1e+77 publickeys will generate its own unique addressId for a 1 to 1 correspondance between all entities. Id like an expert on sha/curve to comment here on these.
Third is the violation between the accountId and the visibleId. Of all the 1e+77 accountId's, 1e+58 of them have the same visibleId of 64bits. 1e+58 is 10000000000000000000000000000000000000000000000000000000000
Once again, for accidental situations, I like these odds, as 1e+58 is waaaaaaaay more than the total number of users to ever use NXT. For cracking though, its another deal. Id have to do further math on the capability of current and future-predicted machines and their ability to crack this.
Obviously, any brute force cracking involved here would be a triple-calculated operation of sha(curve(sha(passphrase))) and be done on all passphrases you wanted to crack on.
I think we all understand how the address space in the 1st case works. That is straightforward. The 3rd case though, seems to indicate that when someone sends NXT to a particular visibleID, that those funds are mirrored in the 1e+58 other accounts that share the same accountId and are available to be sent out once again from any of those other accounts.
But then something doesnt make sense to me b/c then if you add up all NXT from all different accounts, the running total sum of all accounts should be way greater than 1000000000! But maybe the way you examine the blockchain doesn't work that way..
Really waiting on release of the source code (mind you I only completed java 1 and 2 in college, and did no more, so I dont believe Im the guy to review it)
ETA: ok I see how that second address space violation is prevented in the first place. See Jean-Luc's write up later on in this thread...