Topic: BIP 038 Bug (Read 2540 times)

not BIP38 problem probably

Just run through the gambit of browser versions and types.  You'll be fine.  Keep calm and bitcoin on, sir

I am working with a professional to try to recover them. If I don't, then I think I am done with it. I've lost over half my bitcoins to key management problems. If all bitcoin is good for is to make paper wallets and store them in safes, then it isn't a useful technology.

WHen I made my ironkeys with bip wallets on them, I put the setup file for the version of the browser I used as well.  There were various reports as issues with that.

It is possible.

The code should deal with this fine, just out of interest was your passphrase longer than 32 characters/bytes?

NO

Is it possible passphrases are truncated at a certain length?

ummm... that's actually very similar to my passphrase. It was THAT simple, though much longer. And yes, it was over 100 BTC and they are not all mine.

BIP38 is still technically a draft. There hasn't been a huge amount of technical discussion about it. Personally I think there are some weird design decisions and it could be made a lot simpler. Unfortunately, it is being used so much in the wild that a change in protocol seems unlikely.

Just tell him what it is, telepatheic! 


Also, I hope that cbeast recovers his funds, and finds that BIP38 is ok after all. Otherwise, this is pretty bad news.

I've looked into the code: nothing has changed to it since October, and it seems to be doing the right thing, although I haven't looked at it in very close detail. It works now, so it should have worked when you generated it. The only thing I can really suggest right now is that you send me the BIP38 encoded address and I will see if I can work out if there is anything wrong with it (which is a small possibility).

cbeast -

Probably totally irrelevant, but I ran into a similar situation with Bitcoin QT.  
Despite copying and pasting (versus manually typing) my private key passphrase every time, from a source document, I woke up one morning to a wallet that was rejecting that passphrase.
I had a lot.  And I mean a lot ... of Bitcoins in that wallet.  It was stored offline.
Different issue, but strange solution.
I went through every single character and tried its inverse.  Like this:
Known and quadruple verified passphrase which was copied and pasted:  

uPjKmN
Tried:
UPjKmN
then...
upjKmN
then...
uPjkmN
then...
uPjKmn

Switching the case of each character each time i re-tried.
and that worked.
It shouldn't have.

Immediately got rid of QT and put all my sh*t on paper wallets.

I appreciate that. It just seems impossible I could have erred in such a way while sober.

6Pf is the correct format for bitaddress.org I was looking at something else.

6Pf means EC-multiplied keys without compression, I will look into the code and see if I can find anything unusual.

It starts with a 6Pf

Just as a sanity check, does your BIP38 address starts with 6PR or does it start with 6PY ?

Well while I respect cbeast I would say "Exceptional claims require exceptional proof".  So far this hasn't been replicated and thus the most likely explanation is user error.  That doesn't mean it is user error just that it is the most likely.  However it probably would be a good idea to verify your encrypted keys.  The more people that do that the more potential datapoints.

The potential issue however did make me think of a way web services like this could be improved.  Unit testing is a pretty common way to ensure code changes don't introduce bugs.  They usually are done prior to deployment but with browsers being open systems with potential incompatibilities and the fact that javascript is interpreted it might be a good idea for this (and other) projects to do some "inline unit testing" as a form of self check.  When the service loads (maybe just after collecting entropy) it could perform some keypair generation and encryption using known inputs and outputs.  If there is a browser javascript incompatibility that may catch it.  The code takes a known private key X and password P, generates PubKey Y, and encrypted key Z.  The computed Y & Z are compared against the known correct Y & Z.  Depending on execution time it may be possible to run multiple unit tests to provide a level of code coverage.

If nothing else a green "self check = OK" would provide a form of user feedback/assurance.  For the paranoid maybe provide an option a more extensive self check that may take multiple minutes to complete. 

But if its a problem with the software than that guy cant help.

Fuck this could be big, i have some btc encrypted that way too.