Closed mannkind closed 10 years ago
bump - this is important to clarify.
The implementation is probably the correct one, as it will also be what generated the test vectors. I updated BIP38.
@casascius does this require any already implemented code else to be updated? e.g. bitaddress.org?
I don't think so: I'm not sure bitaddress.org even implements the confirmation code portion of it. If it does...I've observed in the past by looking at others' implementations of BIP38 that they are seemingly taking my C# code and translating it sort of line-for-line to produce their implementation, keeping the flow identical... thereby implementing it without depending on, or even looking at, this mistake. I gather that by noticing the similarity between my code and theirs (and am glad that helps it get implemented). I haven't had anyone come to me and say their test vectors failed, which is what I'd expect to see happen if they implemented this error verbatim.
Ok, But as sponsor of the BIP0038 - please make sure people are doing it right. This BIP has addressed one of the most serious issues of exporting private keys - that someone can just swipe your private key - and given how QR codes have so much redundancy in them, it's so darn easy to lose money. Awesome work really! :+1:
So I assume this ticket can be closed now.
P.S. did you get my email?
This ticket can be closed. The wiki was updated here: https://en.bitcoin.it/w/index.php?title=BIP_0038&action=historysubmit&diff=42144&oldid=41942
In section 5.2.2.1 of BIP38 it states that the confirmation code is a Base58Check-encoded concatenation of: "0x64 0x3B 0xF6 0xA8 0x9A + flagbyte + ownerentropy + addresshash + encryptedpointb"
But Model/Bip38KeyPair.cs (~ Line 388) seems to put them in a different order: 0x64 0x3B 0xF6 0xA8 0x9A + flagbyte + addresshash + ownerentropy + encryptedpointb"