Topic: IOTA - page 702. (Read 1473405 times)
Unrelated question, regarding your tryte array (tryteTrits) maybe I'm missing the pattern, but what determined the order of these sub-arrays (Each containing 3 trits) If I were to create such an array, it would have looked like:
This seems to be a semi-natural progression of values. Was there a good, logical reason for the much different ordering of trytes?
Code:
int[][] tryteTrits =
{
{0,0,0}, {0,0,-1}, {0,0,1}
{0,-1,0}, {0,-1,-1}, {0,-1,1}
{0,1,0}, {0,1,-1}, {0,1,1}
...
}
This seems to be a semi-natural progression of values. Was there a good, logical reason for the much different ordering of trytes?
Your order gives the following numerical values:
0 26 1
24 23 25
3 2 4
I've sent alpha version code to those who offered their help. The review shouldn't take much time, it was only back-end code. While we are waiting I'll start writing real (non-reference) version. The difference between these versions is that the latter will be more complex, but optimized.
I had asked a couple questions regarding your comments... I'll dig into this deeper, later. I'm starting to understand.
Unrelated question, regarding your tryte array (tryteTrits) maybe I'm missing the pattern, but what determined the order of these sub-arrays (Each containing 3 trits) If I were to create such an array, it would have looked like:
This seems to be a semi-natural progression of values. Was there a good, logical reason for the much different ordering of trytes?
Unrelated question, regarding your tryte array (tryteTrits) maybe I'm missing the pattern, but what determined the order of these sub-arrays (Each containing 3 trits) If I were to create such an array, it would have looked like:
Code:
int[][] tryteTrits =
{
{0,0,0}, {0,0,-1}, {0,0,1}
{0,-1,0}, {0,-1,-1}, {0,-1,1}
{0,1,0}, {0,1,-1}, {0,1,1}
...
}
This seems to be a semi-natural progression of values. Was there a good, logical reason for the much different ordering of trytes?
FYI, I did a bit of counting. Your address generator calls your transform() function 101(!) times on the state[] array. This means that the seed is hashed 101 times. When I count all of the lookups to F within the transform method, I see 19,683 lookups (which is your number.) This means that F is accessed 1,987,983.
Also, I forgot to stop looking at benchmarks in the debugger (derp!). My i5 is generating about 21 addresses/sec in Visual Studio while outside of VS I'm getting 108 addresses/sec.
Also, I forgot to stop looking at benchmarks in the debugger (derp!). My i5 is generating about 21 addresses/sec in Visual Studio while outside of VS I'm getting 108 addresses/sec.
Some hashings are not necessary to get an address, the logic (not reflected in the code) is:
1. Take random string of trits
2. Hash it to get a 243-trit account seed
3. By adding 0, 1, 2, ... to the seed and hashing it we get different key seeds
4. By hashing each key seed 9 times we get 27 key fragments (a hash contains 3 keys at once because a key fragment is 81 trits while a hash is 243 trits)
5. Each key fragment must be hashed 27 times, after each hashing only first 81 trits are taken
6. Once we get 27 key fragments hashed 27 times each we concatenate them into a 2187-trit string
7. Hashing of this string (requires 9 invocations of SaM transform function) gives 243 trits of the address
This method allows to deterministically generate infinite number of addresses not linked together (for an outside observer) by having a single account seed.
Sorry for my ignorance but is "SaM" hashing the full process of taking a clear text string (the users passphrase) and converting it to an address hash?
Because in your code, you have operations such as 9 hashing rounds x (729 iterations for some left/right calculations + another 729 iterations for left/right index assignments and look ups.) So, that operation alone is 13,122 operations within your transform method... which gets called multiple times per address.
Again, I need to dig into this and figure out the point of each step in your code, but with the exception of initializing the INDICES table just once, I have to execute all of your code for each address.
I hate to ask for a cheat, but are there other ways that some of this could be cached or simplified for barebones address creation?
Because in your code, you have operations such as 9 hashing rounds x (729 iterations for some left/right calculations + another 729 iterations for left/right index assignments and look ups.) So, that operation alone is 13,122 operations within your transform method... which gets called multiple times per address.
Again, I need to dig into this and figure out the point of each step in your code, but with the exception of initializing the INDICES table just once, I have to execute all of your code for each address.
I hate to ask for a cheat, but are there other ways that some of this could be cached or simplified for barebones address creation?
SaM is just a hash function - https://github.com/JinnLabs/SaM/blob/master/src/SaM.java. A single hash requires 19683 lookups to F.
FYI, I did a bit of counting. Your address generator calls your transform() function 101(!) times on the state[] array. This means that the seed is hashed 101 times. When I count all of the lookups to F within the transform method, I see 19,683 lookups (which is your number.) This means that F is accessed 1,987,983.
Also, I forgot to stop looking at benchmarks in the debugger (derp!). My i5 is generating about 21 addresses/sec in Visual Studio while outside of VS I'm getting 108 addresses/sec.
bupqcn01srbheze1o999 -> 81 bits
bupqcn01srbheze1o -> 71 bits
=> mention it.
bupqcn01srbheze1o -> 71 bits
=> mention it.
David will decide, my opinion is that too many details is rather bad than good. If someone managed to send bitcoins then their IQ is high enough to generate a good password.
Come on CfB you know what we mean:
"bupqcn01srbheze1o999" is randomized and fulfills your password suggestion before, but not after, disclosing the "trailing 9"-thing.
"bupqcn01srbheze1o999" is randomized and fulfills your password suggestion before, but not after, disclosing the "trailing 9"-thing.
The security of this password is more than 80 bits, it's more than security of the password used by me LOL.
bupqcn01srbheze1o999 -> 81 bits
bupqcn01srbheze1o -> 71 bits
=> mention it.
Come on CfB you know what we mean:
"bupqcn01srbheze1o999" is randomized and fulfills your password suggestion before, but not after, disclosing the "trailing 9"-thing.
"bupqcn01srbheze1o999" is randomized and fulfills your password suggestion before, but not after, disclosing the "trailing 9"-thing.
The security of this password is more than 80 bits, it's more than security of the password used by me LOL.
So 'qwert999999999999999999' was thought to be more than 20 characters, but it is just 'qwert' 5 characters. I think the average people should know that.
It doesn't look as "randomized order".
Come on CfB you know what we mean:
"bupqcn01srbheze1o999" is randomized and fulfills your password suggestion before, but not after, disclosing the "trailing 9"-thing.
So 'qwert999999999999999999' was thought to be more than 20 characters, but it is just 'qwert' 5 characters. I think the average people should know that.
It doesn't look as "randomized order".
Woww
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
That's correct behavior.
So 'qwert999999999999999999' was thought to be more than 20 characters, but it is just 'qwert' 5 characters. I think the average people should know that.
Woww
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
That's correct behavior.
I think this should be mentioned under step 3 of the "collection manual".
Woww
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
That's correct behavior.
it's interesting! What is the algo again that derives adress from secrect phrase, and how does it give '9' such funny properties?
https://github.com/JinnLabs/SaM/blob/master/src/SaM.java:
Quote
Note that the hash of the empty string is all zeros, this can be used in cases when the hash of NULL should be NULL.
"9" is treated as "all zeros"/NULL.
Woww
What I just tested shows that the any additional '9' or '999999' in the end of the passphrase gives the same address as the original passphrase. But different addresses were returned if '9' or '9999' was inserted in the middle of the original passphrase.
it's interesting! What is the algo again that derives adress from secrect phrase, and how does it give '9' such funny properties?
https://github.com/JinnLabs/SaM/blob/master/src/SaM.java:
Quote
Note that the hash of the empty string is all zeros, this can be used in cases when the hash of NULL should be NULL.
"9" is treated as "all zeros"/NULL.
The java version of the algo seems to look more professional than the javascript one ;-)
it's interesting! What is the algo again that derives adress from secrect phrase, and how does it give '9' such funny properties?
https://github.com/JinnLabs/SaM/blob/master/src/SaM.java:
Quote
Note that the hash of the empty string is all zeros, this can be used in cases when the hash of NULL should be NULL.
"9" is treated as "all zeros"/NULL.
Jump to: