What exactly did they say to do? Can you copy/paste the instructions?

There is not "recovery phrase" feature available for MultiBit Classic... OP is adamant they were using MultiBit Classic and had a 16 word phrase. But those 2 things are mutually exclusive.

So, either they had MultiBit Classic and were also using another wallet like Blockchain.info (that is one of the only known wallets that used a 16 word phrase system) or the OP is simply remembering things wrong.

It would not surprise me if this "Jim Burton" guy had shown this group several wallets that they could use... like, use blockchain.info if you want a "web wallet", use multibit Classic if you want to use a local desktop wallet etc.


And I am very very VERY VERY "affirmative"... that those 16 words have nothing to do with your MultiBit Classic wallet. MBC never used word phrases as a method of wallet backup. MBC backup options were exporting the private keys or copy the wallet file. Those were the only options.

MultiBit HD used BIP39 word phrases, but they were either 12 or 24 words, it did not use 16 word phrases.

Have you tried the blockchain.info password recovery form as I suggested earlier: https://login.blockchain.com/wallet/forgot-password

Does your 16 word phrase work on that page?

This is not the place to try and recover a freebitco.in account... you'll need to contact freebitco.in support. Seems like the only to do that is via a contact form hidden in the "FAQ" section on the website... after you've logged in You might have to create a new account and then contact them using that new account.

But I doubt they'll help much, given this entry on their FAQ:
A password of 12345678 is definitely not a strong password

Bitcoin Core will likely have upgraded the wallet to the new wallet version and then refilled the keypool to have 1000 keys. By default the new versions of Bitcoin Core generate bech32 addresses. You can still get it to generate legacy or nested segwit address, but the default is native segwit (bech32) addresses.

Also, have you tried: dumpprivkey ADDRESS_YOU_WANT_THE_KEY_FOR

How did you load the wallet? All you should need to do is shutdown Bitcoin Core... copy the wallet file into the Bitcoin Core data directory and then restart Bitcoin Core. If you didn't rename the old wallet file to "wallet.dat", then once Bitcoin Core has started up, use "File -> Open Wallet ..." menu command and then select the wallet file.

If you did rename it to wallet.dat, then Bitcoin Core should have opened it up by default.

Any particular reason why you didn't just generate a new Electrum native segwit seed? Did you specifically require a BIP39 compatible seed for some reason?

It's not a fee... it's your "change"...

Think of it like you went to the store and bought something for $12 with a $20 note... you get $8 "change"... Most bitcoin wallets will automatically assign any change to a new address. In your instance, Armory has generated the address 3MxaTKLroUitGF8yftF5VQTEsdtm26xb3Z and assigned the 0.078 BTC change to that address.

More info on "change": https://en.bitcoin.it/wiki/Change

It was actually a parent transaction that got "double spent"... so it seems this person had created a short chain of at least 2 unconfirmed transactions, then double spent the parent.

This then invalidated both the OPs tx: https://www.blockchain.com/btc/tx/7e44600f9066566a4e6e579e0750d5e075f369b7e13fa5dd91896b6eb82cc7b9
and it's parent: https://www.blockchain.com/btc/tx/97c73b235dc0c97c2d59f11f9f03f493cd4d88732d8cde3077bc0d549d15a3e8

what fee rate are you using? and have you checked your network settings? Do you get any sort of error message when you attempt to send the transaction?

Are all you inbound transactions confirmed?

"False" makes it generate "receive" addresses... "True" makes it generate "change" addresses... if you look at the "Addresses" tab (may need to use "view -> show addresses" to see the tab), you will see all the "extra" addresses that you have generated... they will likely be highlighted in red to indicate they are out past the "gap limit".


That *might* explain the differences if the first wallet was showing mBTC while Electrum was showing BTC and you've just missed a 0 and the balances are actually 0.38 mBTC and 0.0004 BTC


As for the differences, it seems like that is just down to sync issues with BRD... the values on the blockexplorers are almost certainly the "true" values that the addresses contain. I would trust them over a potentially unsynced wallet.

Not sure about "recovering"... but it certainly dumps "compressed" keys... the thing you have to remember, is that the private key itself is not "compressed" or "uncompressed"...

It is the public key (and the subsequent hash160 "address") that is "compressed" or "uncompressed". The private key is always a 256bit number.

I think the "new" fields were added when HD wallet support was introduced which was in v0.13... which was released in August 2016... so a wallet created in 2015 should be the old "non HD" wallet type. However, if it was subsequently opened in a newer version of Bitcoin Core, the wallet file was likely "upgraded" (not to HD, but to the new format) which may have added in the fields that cause issues with PyWallet.

This is why I recommend making copies of the original 2015 wallet.dat file and working on the copies.

Again, have you simply tried opening one of the copies of the wallet.dat in Bitcoin Core and using either dumpwallet or dumpprivekey from inside Bitcoin Core? It would be much much easier than trying to deal with PyWallet and it won't matter if the wallet file is old version or new version.

Ahhhh ok... yeah, an article I was reading a couple of days ago regarding the lawsuit seemed to be implying that the 2 were the same thing... it may have just been the article was poorly written or that I completely misunderstood what they were saying (most likely the later! )

That other user doesn't have the contact details for this "Bitsave"... they were just offering general advice for how to recover your account. However, if the website is closed as you said, then you won't be able to email them anyway as the entire domain is likely long gone.

What are the names of the 2 files in your "Bitsave" folder?

Then the other explanation might be the "gap limit" of Electrum... and your coins are "hiding" in an address that Electrum is not "seeing" because it only generates up to 25 "empty" addresses and then stops looking. You can read about the "gap limit" here: https://electrum.readthedocs.io/en/latest/faq.html#gap-limit

To generate more addresses you can use the command on the Electrum "console" (you might need to use "View -> Show Console" to see the console tab):

Every time you type that, it will generate 50 more addresses... you can change 50 to whatever number you like, but you probably don't need to generate more than a few hundred to be relatively sure that the "missing" funds are not hiding past the gap limit.

to be 100% sure you should also try:
which will generate 50 extra "change" addresses so that Electrum can check those too.


Simply go to a blockexplorer like one of the following:
https://btc.com/
https://blockchair.com/bitcoin/
https://live.blockcypher.com/btc/
https://www.blockchain.com/btc/
https://blockstream.info/

and enter your address(es)... see what the "current balance" displayed for the addresses is... if it adds up to the amount shown by Electrum, then Electrum is probably not missing anything due to the gap limit... and the "big balance" you're seeing is just because things were not syncing properly when you used the "Fast sync".


No... he means "denomination"... Electrum defaults to using mBTC (or milli BTC)... you need to use "Tools -> Preferences" menu... look on the "General" tab and see what the value for "Base Unit" is.

It's possible there might be some confusion between mBTC and BTC (or vice versa)... but mBTC should be showing as 1000 greater... not 100 less

ie. 0.38 BTC == 380 mBTC ... and 0.3 mBTC = 0.00038 BTC

You can try those code alterations... or use my version here: https://github.com/HardCorePawn/pywallet

It essentially has the mods as shown by the commits here: https://github.com/jackjack-jj/pywallet/compare/master...HardCorePawn:master


But before messing around with PyWallet... have you just tried installing Bitcoin Core and opening a copy of the wallet.dat from 2015 that has the address you're after in it?

It would be much much simpler to use dumpprivkey from within Bitcoin Core (it doesn't even need to be synced or connected to the network) and get the private key that way than trying to use PyWallet.

And of course, regardless of whether you are using Bitcoin Core or Pywallet, you'll still need to know what the wallet passphrase is to be able to access the private key.

Yeah... unfortunately, there will probably also be the requirement to prove "willful negligence" on the part of Ledger and Shopify with regards to their security practices and whether the hack was due to them being negligent, or just the "hackers" being clever/abusing 0day vulnerabilities etc... will be interesting to see how those "Liability" disclaimers in the Terms of Service etc hold up in court.

I'm also a little confused as I've seen somewhat conflicting information that this "hack" was actually an inside job conducted by one or more Shopify employees who abused their position to access/copy the data and then sell it on the black market.

Which seems somewhat at odds with the reports of the "bug bounty" that some guy found a "misconfigured" API key that enabled external access etc.

No... unless there is another route from Alice to Charlie (or vice versa), there is no way they can send to each other...

Alice can send up to 10 mBTC to Bob.... Charlie can send up to 10 mBTC to Bob... but currently, Bob has no capacity at all, so is unable to send anything to anything to anyone.

So, the Alice->Bob and Charlie->Bob routes are essentially "one way" at this point in time... as Bob->Alice has 0 mBTC capacity... and Bob->Charlie has 0 mBTC capacity.


Alice 10mBTC ----- 0 mBTC Bob 0 mBTC ----- 10 mBTC Charlie


Now, if Alice was to send 5 mBTC to Bob... then it would look like this:

Alice 5 mBTC ----- 5 mBTC Bob 0 mBTC ----- 10 mBTC Charlie.

Now... Charlie could send up to 5 mBTC to Alice... as that is the max capacity available on the Bob->Alice route. Alice is still unable to send anything to Charlie, as the Bob->Charlie route still has 0 mBTC capacity.

100% that your 16 words did not come from Multibit Classic nor Multibit HD.

16 words sounds like an old blockchain.info (now blockchain.com) password recovery phrase... especially given that none of the words are in the BIP39 list. The blockchain.info legacy password recovery used a completely different list to BIP39.

You can check your 16 words against the ones in this (very long) list: https://github.com/blockchain/unused-My-Wallet/blob/ddbb0995fbdb2b5f22bef9eb92a26e2bfefb6e00/mnemonic_words_v3.html


Note that this 16 word "recovery" phrase will NOT recover your wallet. It will only recover the password to your wallet.

Refer: https://login.blockchain.com/wallet/forgot-password


Unfortunately, if you don't have the original wallet.aes.json backup file from blockchain.info or some record of the "wallet id", then this 16 word phrase will be of very little use to you. Given that your old computer is "dead", then I'm going to guess you don't have the wallet.aes.json file...

Do you perhaps have access to the email address that was registered to blockchain.info and/or an old email from blockchain.info stored in your email account with either a record of your wallet-id or perhaps even an email with a copy of the wallet.aes.json backup file attached?

You should be able to confirm that it is indeed your change address by clicking "Wallet Properties" and then expanding the "Change addresses" section. You should see the 3MxaTKLroUitGF8yftF5VQTEsdtm26xb3Z address listed in there.

Has there been any progress on a "standardised" method for signing messages using bech32 addresses yet?

I haven't really been following along to the tech developments as well as I ought to be (due to "reasons"), but it is one reason why a lot of people were still clinging on to at least one or two legacy addresses due to "Airdrops" etc requiring signed message for registration etc.

Although, I dare say that it is probably not so much of a issue these days as we don't quite have the ICO overload like back in 2017

Just out of curiosity... how did you find the "working" password? Did you have a bruteforce script running that was trying all sorts of unicode characters in addition to the standard aA-zZ0-9 + "specials"?

Or were the unicode characters "accented" characters like you'd find in french and other european languages? like à etc?