ECKey$MissingPrivateKeyException

[GoogleCodeExporter]

We've got one occurence of a missing a private key:

Exception in thread "main" org.bitcoinj.core.ECKey$MissingPrivateKeyException
        at org.bitcoinj.signers.MissingSigResolutionSigner.signInputs(MissingSig
ResolutionSigner.java:84)
        at org.bitcoinj.core.Wallet.signTransaction(Wallet.java:3548)
        at org.bitcoinj.core.Wallet.completeTx(Wallet.java:3467)

The mobile phone that was used for the wallet (ZOPO ZP998) also experiences 
"Bit-flip check failed" exceptions, so there is a possibility it is faulty. 
Still, I'd like to rule out a more systemic problem in our software.

Original issue reported on code.google.com by andreas....@gmail.com on 23 Jan 2015 at 11:24

[GoogleCodeExporter]

According to the reporter, he did not tamper with the wallet file or backup 
file and also he is using the official stock firmware of the phone.

Original comment by andreas....@gmail.com on 23 Jan 2015 at 11:25

[GoogleCodeExporter]

Probably related: the guy tried to restore from his only backup file and failed 
to recover the funds. The reason as far as I can see is the xpub (and derived 
addresses) in the backup doesn't match with the 12 words contained in the 
backup, so he received his coins into the void.

He admitted his SD card is faulty (Android complained "Damaged SD card, try 
reformatting it"), but I'm not entirely convinced this is the (only) reason for 
his problems.

Original comment by andreas....@gmail.com on 26 Jan 2015 at 2:17

[GoogleCodeExporter]

This is the phone that appears to be randomly corrupting RAM, has a broken SD 
card and is also seeing other issues? I'm not sure we can expect any kind of 
deterministic behaviour from such a device. It sounds like somehow this phone 
is in a twilight zone where it's too broken to operate correctly but not quite 
broken enough to die.

What would you like me to do?

Original comment by mh.in.en...@gmail.com on 27 Jan 2015 at 2:40

[GoogleCodeExporter]

So far, we only know that the SD card is/was faulty somehow, see comment #2. 
Even if the RAM flips bits, I wonder how this can lead to a "missing key" 
(rather than a much more cryptic exception, e.g. a VM crashing).

I know there is not much to win. Still it might be worthwhile to think about 
protections, such as a checksum for persisted data or more consistency checks.

Original comment by andreas....@gmail.com on 27 Jan 2015 at 3:24

[GoogleCodeExporter]

The bit-flip exception you reported via email *is* a consistency check. Is the 
issue here that we didn't abort/freeze operation once it was thrown? Perhaps 
bitcoinj should handle this at the library level and record the fact that it 
happened, then refuse to do anything from that point onwards?

I guess we need to start thinking about how to handle broken hardware more 
systematically.

Original comment by mh.in.en...@gmail.com on 27 Jan 2015 at 3:39

[GoogleCodeExporter]

BTW I am not sure why the missing key exception is thrown. It implies that 
somehow the root private key didn't load or went walkies somehow. But I'm not 
sure how that can happen. OTOH broken hardware can do anything. Perhaps there 
is some issue when the bit flip exception happens that puts the system into a 
state where it can lose private keys (or rather, lose them more). Trying to 
simulate it might be worth doing.

Original comment by mh.in.en...@gmail.com on 27 Jan 2015 at 3:43

[GoogleCodeExporter]

I know it is a consistency check, which is why I prefixed it with the word 
"more" (-:

Generally exceptions already lead to refusing to do anything. Until you restart 
the app of course -- do you think of freezing preventing app restarts as well?

> I guess we need to start thinking about how to handle broken hardware more 
systematically.

That is what I was trying to say. I think some parts of bitcoin software (such 
as key handling) must be really defensive.

Original comment by andreas....@gmail.com on 27 Jan 2015 at 3:47