Any one else experience the coinbase pro issue where all the coins disappeared (they just came back) and you could not see or sell them?

This was in mobile and online...

I took screenshots and video.

[url]https://imgur.com/a/arUeNS2

The old encryption actually consists of 2 parts.  A master key is hardened and encrypted with your passphrase.  This is what you lock/unlock when entering it.  The private key is then encrypted with the plaintext of the master key + 2xSHA256(public_key) as the IV.  In order to decrypt a private key you need the plaintext of the master key + public key (which is typically stored in plaintext in the wallet).

If I had to guess - you either have an unencrypted private key already, just in a different format OR the tools errored when trying to process the wallet file because its corrupted.

Since you are dealing with corrupt data you need to do byte by byte computations/comparisons.

Thanks - yes I have that.  I was investigating the encryption bug on 0.4.  It stored keys in plaintext (even for encrypted wallets) in the wallet.dat, logs and __db00X files per Gavin here:  https://bitcointalk.org/index.php?topic=51474.msg616068#msg616068

We have had success finding them in the wallet.dat however the logs and __db files have been a bit more difficult to process.

I was wondering if the master key got mixed up in this db issue as well.   It would provide an alternate means of unlocking the private keys as in my case half the wallet was floating around in plaintext but my addr with coins on it happened to be in the other half.  =)
 

Encryption was implemented in core v 0.4.  A master key was added that encrypts the private keys.  (The master key itself was encrypted via various mechanisms). The master key unlocks the private keys.

Is a master key in the old JBOK wallet simply a private key (with a different name) ie is it the same format as a private key?  I am trying to scan individual bytes to look for it as this wallet was not born encrypted....OR does it just generate a master key on the fly when you encrypt ?

ie a private key typically starts (back then) as 0x01 0x01 0x04 - are there any telltale signs of an unencrypted master key?

Is the wallet encrypted?  If not why not just scan the HD contents (assuming it can be mounted) looking for the private keys?

Its relatively straightforward, no cracking or anything is needed.

.4 clients (encrypted or not) often left private keys able to be extracted in plaintext, it was a known bug.  In my case 50% of the private keys were left in the encrypted wallet in plaintext and there are other places to look for traces as well.  We wrote our own stuff but there is code floating around.

Prob not, its complicated.

Our setups took a bunch of time to perfect.

Where exactly is the bug outlined? Called?  I see numerous mentions of it all over as "Password issue" but not exactly what the bug was.  I do not know the exact pwd and can crack keys pretty easily but I am not finding it (ie we know what chars, how long etc, but it not being found).  We have done it on a bunch of test cases fine.

I am trying to see how it could impact the hash used for cracking if at all.  Add into the mix a non US non EN keyboard was used.

To clarify it was  multibit classic wallet ~early 2014

Any help would be great.

Thank you for the confirmation!

Hi - long story short, been going over the original spec for wallet encryption, and the dynamic number of SHA rounds used in a wallet for core ~.4.

https://github.com/bitcoin/bitcoin/blob/6b8a5ab622e5c9386c872036646bf94da983b190/doc/README

Lines 77-79

Is this meant to be taken literally, in that given a wallet encrypted on machine 1, with a dynamic number of rounds X, if that wallet is moved over to a new machine and subsequently opened/decrypted - would X stay the same or take on the specs of machine 2?  (It appears it would only change if pwd is changed)

We are working on a recovery for an owner with multiple wallets.  Our process has been to go after the one with the least amount of SHA iterations (obviously bc its faster) even tho that is the one without the coins in it, under the assumption the pwd is the same or similar to the wallets with higher SHA rounds and at the worst will provide confirmation of pwd formatting possibly used in the harder wallets.

I am just trying to account for any reasons the wallets rounds may be different.

1) Pwd changed on a new faster machine
2) Brand new wallet on new machine (also possible bc the addresses are different, although it could make sense he used a similar format for new wallet)
3) ***Wallet opened on new faster machine but pwd is not changed

#3 is what I am asking about.

Thanks!

Given we have:

1) a wallet.dat file with ~100 addresses.
2) 40 addresses in the same wallet, with addr, pub keys, encrypted private keys AND unencrypted private keys
3) mkey with: {crypted key, salt, and nDeriveIterations, etc)
4) Anything else we need from pywallet, etc
Is it possible to find the password for the wallet as a whole OR the unencrypted private key for one SPECIFIC address in the wallet file assuming we have the pub key, addr, and encrypted key for that address (along with mkey).

Note these are all addresses in the SAME wallet.dat, encrypted at the same time with same password and we could recover unencrypted private keys for ~40 of them (but not the 1 addr we want).

My assumption is no, because your wallet would be exposed when you spend a coin (if someone who has received coins from you got ahold of your wallet).

That being said, what do you think would be faster, assume pwd is in dictionary list...

1) Trying various passwords from a dictionary and encrypting priv keys in wallet and checking against their known encrypted verion?  (And then knowing pwd for wallet)
2)  Doing same as above, except trying to decrypt against a dictionary and matching to know unencrypted values
3) Using some GPU tool like btcrecover and brute forcing it.  Depending on GPUs etc, you can get 1k pwd / s to 50k pwd/ sec.

I have tried messing around with js bip38 tools etc, but none seem to work atm or I would be timing this.

EDIT: This is different then cracking, as you 1) have the wallet 2) have unencrypted/encrypted private keys in the same wallet.

Thanks