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.

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.

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

Entropy is a measure of uncertainty in a system. It is relative, not absolute. It makes sense to talk about entropy only if you clearly define what is your prior knowledge of a system. In our case, we need to look at how many bits of uncertainty there is from the point of view of an attacker. In general, in order to crack a n-bits seed, an attacker needs to perform 2^n iterations of public key generation.

If we impose a constraint on the seed, namely that its hash starts with a given prefix of length m bits, this does not reduce the number of iterations an attacker has to perform. The attacker still has to enumerate 2^n seeds and test them. Therefore, it is incorrect to claim that we are reducing entropy. The only thing that changes is that the test function will return faster for invalid seeds (because it does not have key stretching). So, what we are losing is the benefit of key stretching on m bits. But we are not losing m bits of entropy.

To understand that these bits are not lost, consider an extreme case where the seed has 132 bits and the prefix has 64 bits. Would you say that we have lost 64 bits of entropy? no, because it has become incredibly difficult to generate a seed. An attacker still has to go thought these 2^64 iterations, before they can test each of the remaining 2^64 public keys.

Note that it is possible to express the benefit of key stretching in "bits", although that's a bit like adding oranges and apples. Nevertheless, if you consider that key stretching increases the number of "bits" of your seed, you have to understand that it only adds a constant. The strength of a seed increases exponentially with its length, and only linearly with the number of iterations of key stretching. What we are losing is a fraction of this constant.

it is likely that someone else (a physical person or malware) setup the default wallet in order to steal your coins.

The seed has 132 bits and the length of the prefix is 8 bits. Therefore, 8 bits are "lost" by imposing the 0x01 prefix.

However, there is no way to enumerate seeds that hash with the desired prefix, other than brute force. Therefore, from a security point of view, these bits are not "lost"; an attacker still needs to use brute force in order to find valid seeds, just like they need to use brute force in order to attack the remaining bits.

There is still a weakening of the seed that results from the imposed prefix, because no key stretching is required in order to generate the prefix.
But it is wrong to express it in terms of "bits lost"; all you can say is that these 8 bits are easier to enumerate than the remaining 124 bits.

the current APK does not support hardware wallets. we are working on this.

the bug corrupted your wallet file.
you need to create a new wallet file with your seed.

note: OP posted here https://github.com/spesmilo/electrum/issues/2098

I can reproduce your issue.
it has the same cause as this other bug: https://github.com/spesmilo/electrum/issues/2097

the bug was fixed earlier this morning.
you will have to wait for the next release (planned for today or tomorrow), and then restore again from seed.

thanks that's the information I needed

this looks like a bug.
can you post more information?
(android version, language preference, etc)

is it a standard wallet or multisig?

we removed the logic that handles several accounts in the same wallet file and gui window.
accounts are now handled in separate files.
it also improves user privacy.

Thank you for your post. Although I mostly disagree with your ideas, it gives me a good opportunity to explain what I think.

Electrum is both an open source project and a company (Electrum Technologies).

I created the company in order to:
 - distribute the software through a legal entity.
 - provide support for corporate users.
 - accelerate development.

The monetization ideas you listed in your post are not original, and have been considered already. The company is currently earning money on consulting, and on the Trustedcoin plugin.  A few other monetization ideas are in development.

I have been contacted several times by VCs who wanted to invest in Electrum (the company).
After several inquiries, I have decided not to follow that path, for the following reasons:
 - I believe that software quality is generally better when people write it for fun, than when they are getting paid for it.
   (it is not a question of competence, it has to do with long-term commitment to fix the things you do wrong.)
 - I would not be having fun if I was working for VCs.
 - I believe that the Silicon Valley model of development (grow fast, pay investors later or die) does not suit well Bitcoin.
 - As far as the company is concerned, I prefer organic growth. (maybe it has to do with your typical Bitcoiner's debt aversion syndrome).

What's wrong with the Silicon Valley model applied to Bitcoin? Well, despite what you can read in various Bitcoin media, Bitcoin's growth is comparatively slow. (I mean, slower than companies like Ebay, Facebook, Amazon, etc.), because its userbase grows slower. I believe this is because people are generally more conservative with money and savings, than with signing up on a social network. As a result, the competition between Bitcoin companies is more a marathon than a sprint race. What Bitcoin needs is long-term commitment, and not companies that go bust when they are out of VC money.

When it comes to using funds, there are 3 things where Electrum could benefit from money: development, servers, distribution.

1. Development:
First, your observation that development is slower today is wrong. You are not seeing the whole picture; development effort is not proportional to the number of commits or visible features. Most of the Electrum software has been developed by myself and developers doing this on their free time. Other parts of the code have been developed by external companies, or paid developers. I believe paid development should be funnelled to the aspects of the code that are not handled well by developers working on their free time.

2. Servers:
Currently there is no shortage of free servers. The new server code (ElectrumX by kyuupichian) has made it much less resource intensive to run an Electrum server.
Paying servers have already been discussed. So far nobody has been running a paying server successfully, because of the competition of free servers.
I think it will be possible to have paying servers once we have support for payment channels in the client.

3. Distribution & packaging.
This is something where money can be useful, because it is typically not very exciting for developers working on their free time. This is the primary reason why the company was created. I hope to be able to hire someone this year, btw.

still a go. it will be the same interface as the Android version.

ElectrumX is pretty stable and fast. It is now linked from electrum.org, in replacement of electrum-server

I do not understand what you are talking about, and it looks like you really don't know what you are talking about.

SPV is a verification of the transactions sent by the server.
That verification is performed by the client, independently of the server.
That verification involves fetching block headers from various nodes and verifiying miners proof-of-work.

"nodes cant fool the server" is completely pointless here (and meaningless).
the point is that the server cannot fool the client.

no, that has nothing to do with the server, it is just the result of your recent connection history.
the SPV module guarantees that you are connected to at least 8 nodes.
your main server is one of them; if you switch to another server for any reason, it will be added to the list.

our algorithm is not proprietary, any other wallet can use it.
some documentation here:
http://docs.electrum.org/en/latest/seedphrase.html

the wallet history is fetched from a single server.
that server cannot give you fake TX data, because Electrum verifies the data using SPV.

block headers are fetched from 8 different nodes.
please document yourself about how SPV works. it does NOT work by comparing data from random servers.

we are working on it.

use 'addrequest'