Quote from: ThomasV on January 28, 2017, 11:17:56 AM

Quote from: bitsec731 on January 28, 2017, 09:35:29 AM

...
Is that a correct assesment?

No that is not correct.

First, we are not talking about 2 but 8 bits. I do not know why you made that statement about 2 bits.

I think you misunderstood me, please re-read my post. Let me explain it better

I have tested that in hex mode, every input loss = output loss ( +/- some variance at certain bits, but it converges to this).

Which means that for N fixed output characters, you have N fixed input characters.

The code fixes 2 hex characters "01", and we know that 1 hex character is 4 bits. So that is 2*4 = 8 bits of entropy lost.

Quote from: ThomasV on January 28, 2017, 11:17:56 AM

Second, we are not fixing the bits passed to bip32_root. The seed passed to bip32_root is not hashed with "Seed version", but with a different string. That assumption seems to be present in the last part of your reasoning.

Of course ,I havent said that it's like this, that was just a side tangent. I actually said that the bit32_root has nothing to do with this.

Quote from: ThomasV on January 28, 2017, 11:17:56 AM

Third, and this is the most important point, there is no 'loss' of entropy.

Yes there is, because if you fix the output, you fix the input.

If SHA-512 is bijective, which it isnt entirely, but that is another issue. So if we suppose it is.

Then if we have 2^512 combinations a hacker has to solve to get the key.

If we fix 8 bits of entropy, that means only 504 bits of entropy for the SHA512, and only 124 bits of entropy for the input, since the input must conform to that criteria.

Because only 2^124 number of seeds translate to 2^504 bits of entropy of the SHA512, and the remaining 8 bits have 0 entropy.

Now here is the conclusion:

So you are saying that computationally this doesn't make a difference, but I disagree. Because entropy is just information, and it get's carried forward.

Because you have a -8 bit deficiency, and only 124 bits get passed on to the bip32_root to generate the xpriv and the child priv keys from there on.

It's not that the 2 SHA outputs collide, don't misinterpret my word, that is not what it is. It's that the is_new_seed function is limiting the possible inputs by 2^8 combinations, which result in a 8 bit entropy loss by definition.

So a default wallet creation goes like this:

1) 132 bits of initial entropy pool
2) limited to 124 bits to create seed words at is_new_seed
3) 124 bits to master private key at bip32_root
4) then 124 into bip32_private_derivation or whatever that creates child priv keys
5) then 124 bit into ECDSA
6) then 124 bit into RIPEMD-160
7) Then Base58 encoding and you have a 124 bit address.

Furthermore, every hashing leaks about 0.5 bits of entropy if the input is smaller than the capacity of the hash, because the hashing functions are not bijective. Who knows maybe RIPEMD could leak up to 1 bits because the input almost depletes it's capacity. Not to mention that the BTC address also has an encoding scheme (they start with 1 or 3), so add that to it as well.

So you could easily end up with a 120 bit Bitcoin adress (in both spent and unspent state) despite the original entropy pool being 132 bits.

Whereas if we compensate for the lost 8 bits (in electrum), we could create a seed that is 168 bits, so that an unspent BTC address could be a maximum 156 bits strong. And a spent BTC address 124 bits.

Unfortunately the RIPEMD-160 is a very weak algorithm, that is where most of the entropy is lost. It should be replaced with something bigger of 256bit.