Quote from: ThomasV on February 10, 2017, 01:31:32 PM

I perfectly understand your argument.

Yes, the number of valid seeds is shrunk.
But that does not matter, because an attacker still needs to enumerate all seeds, in order to know if they are valid.
So, we are not reducing the size of the haystack.

It is as if you were claiming that the number of possible combinations is one because in the end there is only one seed that matches the private keys.
With that kind of reasoning, the entropy of anything is zero.

The problem is that you do not understand what entropy is. I think there is no point continuing this discussion.

Btw, raising the num_bits parameter to 132 would have no effect at all; math.ceil() already ensures that n is a multiple of 11 bits.

It's a hard mental excersize, and this does matter, maybe the missing bits are not as much, but it's still not good to misrepresent it.

For me security is important, hence my name, so let me explain it in a simple way.

THREAT MODELING

There are 5 layers in the Electrum Wallet:

1. Attacking the Bitcoin Address
2. Attacking the Public Key
3. Attacking the bip32_private_derivation output
4. Attacking the bip32_root output
5. Attacking the is_new_seed output
6. Attacking the seed

6. If the attacker has the seed, then it's already over.
5. The is_new_seed output has 512bit security, so even if it's made public, which it has no reason too, it's theoretically safe.
4. The bip32_root output has 512 bit security, so it's the same as above
3. bip32_private_derivation is just an encoding mechanism so, there is no entropy change here, and it's as vulnerable as the seed
2. The public key has a maximum security of 128 bits if made public
1. The bitcoin address has a maximum security of 160 bits if made public/ or is already public

Now as you have seen, the 6. and 4. points have 0 security, but they are not made public anyway, it's just handled internally, or on an offline machine if done so.

So the only thing that goes public is the public key and the bitcoin address. In case of a bitcoin address, if it's unspent it remains 160 bit, if it's spent, then 128 bit.

So far so good. But my point was that the input entropy is too low, due to flawed generation.

Think of it like a car engine, if you feed only 124 bits of entropy into it, the output will only be maximum 124bits (and possibly lower due to collisions).

So it doesn't matter that we have 512bits shield at point 5) and point 4), those values are private anyway, because it's handled in the memory.

What I am saying is that the is_new_seed function is lowering our entropy by 8 bits regardless of what we feed into the make_seed function.

I don't know how else to explain it to you, just test out my code and see for yourself:
https://bitcointalk.org/index.php?topic=1761663.msg17802165#msg17802165

Quote from: ThomasV on February 10, 2017, 01:31:32 PM

Btw, raising the num_bits parameter to 132 would have no effect at all; math.ceil() already ensures that n is a multiple of 11 bits.

You still don't understand what I am saying to you. Please read my post carefully.