Ledger are offering 40% off all of their hardware wallets from November 23rd-30th... promocode is: blackfriday20 (you apply it at checkout)

I thought they might have offered even more given the problems surrounding the data breach and ongoing phishing attacks... Even at 40% off, I think it might be a hard sell for a lot of people.


Anyway, you can read more about it here: https://shop.ledger.com/pages/black-friday

I concur with Bitmaxz... it looks like your Bitcoin Core might be running in "pruned" mode. Armory needs a "full" copy of the blockchain, it can't work with a pruned Bitcoin Core.

In Bitcoin Core GUI, check "Settings -> Options -> Main":


Is the highlighted option checked or unchecked?

If it is checked, your node is pruned and you'll need to unchceck it, then shutdown and restart Bitcoin Core. NOTE moving from "pruned" to "unpruned" will required that your node redownloads and syncs the entire blockchain again!!


Also, on that same settings dialog, you should click the "Open Configuration File" button at the bottom and check to see if there is a prune=xxx entry in your bitcoin.conf file. If there is, you need to remove it.

Correct. The co-signer will also need to create a copy of the "2-of-2" multisig, using the xpub from the original multisig wallet, and their own seed. So, person 1 would create the multisig using "Seed1 + xpub2" and person 2 would create the multisig with "Seed2 + xpub1"

If the co-signer loads a partially signed multisig transaction into a "standard" wallet, they'll see "Transaction unrelated to your wallet" message like this:



However, if the co-signer creates a copy of the multi-sig using their seed and the xpub from other signer, then when they load the partially signed transaction, Electrum will then detect that the transaction belongs to the wallet and enable the co-signer to sign and broadcast the transaction:

Have you confirmed that "THE_ADDRESS_OF_THE_WALLET" actually still contains bitcoins?

If you go to a blockexplorer like:

https://blockstream.info/
https://btc.com
https://blockchair.com/bitcoin/
https://live.blockcypher.com/btc/
https://www.blockchain.com/explorer

And enter THE_ADDRESS_OF_THE_WALLET into the search bar (DO NOT USE THE PRIVATE KEY!!)... you will be able to check the current balance. Make sure that it actually contains coins before you bother exporting/importing private keys


Fully syncing Bitcoin Core with the wallet.dat will take longer and requires a fair amount of bandwidth (and possibly data storage if your node isn't in "pruning" mode)... but at least you can be assured that the balance at the end will be correct and it will show any and all coins for all the addresses in your wallet.dat.

Yes, the -rev files are used to basically rollback to the starting point where the new (longer) chain starts, and then validate the transactions in the blocks. Basically, it reverts all the spent inputs from the "old" chain back into UTXOs (unspent transaction outputs), so it can then determine whether the inputs in the transactions in the "new" blocks are actually valid etc.

I haven't used Litecoin Core in about 2 years... but my leftover litecoin data directory from 2018 still has rev****.dat files in the blocks directory. I installed the latest version 0.18.1... and after it had "updated the UTXO database", the rev****.dat files still exist. So, I'm not sure why you don't have these files?


Are you running in "pruned" mode? Is the highlighted box in "Settings -> Options -> Main" checked or unchecked?

Out of curiosity, what does that actually "check" to determine validity?

Does it just check the first X addresses generated? if so, is "x" configurable and does a higher number like 20 or 100 cause a significant increase in time required?

Best of luck to you, but unfortunately, I don't see this having a happy ending

This case is a prime example of why an offline, "physical" backup (ie. writing it down or using a "cryptosteel"-type solution) is the recommended method to backup a 12/24 word seed mnemonic. Hopefully, it might save someone else from the same fate by convincing them that relying on "memory" alone is a "Bad Idea"™

And you won't ever own much BTC if you keep impulse buying hardware wallets! hahaha

Still, I'd be keen on a review once you receive the wallet... To me, it's basically just a physical "coin" in plastic card format... huh, I only just realised they're made from stainless steel!!?!

Obviously, the total number of possibilities with 2 missing words is a lot less than the total search space of 12 word seeds... I was simply pointing out that "12 factorial" was not the correct starting point.

Most of the utilities simply create the combinations dynamically, rather than generating a dictionary of every possible combination first... which is rather wasteful, given it might take only a relatively small number to find the correct one.

So basically, the idea is that you create a given combination, calculate if the checksum is valid and discard the seed mnemonic if it fails... otherwise move on to the more computationally intensive task of actually deriving keys/addresses etc.


At the end of the day... trying to find 2 missing words is actually relatively trivial, regardless of whether the position of the missing words is known, but only if the 10 you already have are in the correct order. A script should be able to find the correct combination of 12 words in a relatively short amount of time.

However, 7 words is going to be, for all intents and purposes, "impossible"... you'd be looking at a timeframe measured in centuries or thousands of years

Unfortunately, you are wrong... a 12 word seed has 2048^12 possibilities => 5444517870735015415413993718908291383296 total possibilities (the actual number of valid possibilities is a bit less due to the checksum requirements etc).


The multiple devices don't talk to each other... you provide the --worker argument as "n/m" (ie. --worker 1/5) on each worker and it will divide the password search space up into "m" chunks and assign chunk "n" to that particular worker.

If you watch the demo of using Vast.ai with multiple instances here: https://www.youtube.com/watch?v=8Zqc-2Te3zQ&list=PL7rfJxwogDzmd1IanPrmlTg3ewAIq-BZJ&index=13&t=1220s

You can see him say "they don't communicate at all" and some of the other workers are still running, even when one had found the password.

The written instructions for this demo is here: https://github.com/3rdIteration/btcrecover/blob/master/docs/Usage_Examples/2020-10-06_Multi-GPU_with_vastai/Multi-GPU_with_vastai.md

What does it say in the bottom right corner of the Armory window for the number of blocks and status? "Online", "Offline"? and is the text written in green, red or purple colour?

In any case, the update from the old version to the new version might have led to some incompatibility with the database info... I suggest you follow BitMaxz suggestion and use the "Help -> Rebuild and Rescan Databases" option within Armory to see if that clears it.

If you're still having issues after doing that, then take a new copy of your log files, and repost to pastebin.

Pretty much a "What is more important to you?" type question...

If you're overly cost sensitive, then the Ledger/Trezor options are probably the "best" for your situation... if you don't want to support a company that has relatively poor customer support and a history of somewhat dubious development decisions (why fix long standing bugs when we can implement support for shitcoin#5435344! ), then the Ledger might not be your best bet and you'd perhaps be wanting a Coldcard or Trezor.

Trezor obviously has the "seed extraction" vulnerability, so requires either using the BIP39 passphrase (and/or the SD encryption functionality of the model T)

Coldcard has not experienced any major vulnerabilities that I'm aware of, but obviously comes with a higher price tag.


You'll need to figure out what your particular requirements/constraints are and choose accordingly.

Yes, sadly... not all microUSB cables are created equal... aside from the "power only" vs. "power+data" cables, the Nano S (and/or Ledger Live) seems to be quite "sensitive". I have a cable that operates quite nicely as a data cable for my Trezor ONE, but with the Nano S, it often "drops" the connection and Ledger Live won't detect the device, even though it is still powered. So, I think the cable might be slightly damaged as it is a few years old and perhaps the damage is what is causing the issue with the Nano S.

But it can be "re-orged"...

as per the wiki, the "undo" is for rolling back the chainstate:

More indepth reading of what rev*.dat files are: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage#Raw_undo_data_.28rev.2A.dat.29

what happens if you just use the command:

Do you get the same error?

That simply isn't true... and "keeping it simple" is not the answer here. Some wallets (like Bitcoin Core) don't even have "random words".

The correct requirements, as already stated by bob123 are:

Following on from this, it should also be somewhat obvious that a thief/hacker also only needs access to ONE of those three things to steal all your coins... therefore you should take necessary steps to prevent them from falling into the wrong hands.

An initial multibit wallet holds 1 key... by default it'll be somewhere around ~164 bytes... it could be a bit more if the user-defined "wallet description" that you enter within the app is quite long... Adding another 20 keys will extend the size out to around ~1790 bytes... a wallet file with 101 keys (and no transaction or other data) is around ~8100 bytes...

They use a "protobuf" format... it is basically just straight serialization of text, so it doesn't have much overhead like the Bitcoin QT LevelDB format. So, I would say that a 9k file isn't really "too small" for a multibit wallet file.


The reason the script found ~9000 keys is because it stepped through 1 byte at a time, read the next 32bytes and used that to generate a private key... It did this as there was no way to determine which exact 32 byte sequence was a private key (if any), as the OP could not find the "1A4E08011220" byte sequence which is the "marker" for private keys in an unencrypted multibit wallet file.

Again, I suspect the recovered file was simply too damaged to be useful.

As an update for the interested observers... I've spent a few days trying various tihngs with the OP... initially they tried my multibit recovery scripts, but they were not able to read the wallet file as a "wallet file"

Then we tried inspecting the wallet file to see if it was encrypted or not, it does not appear to be an encrypted file.

Then we tried inspecting the wallet file using a hex editor looking for specific "key" markers... but they were not found. This was not great news and indicative of the file being badly corrupted and no keys being salvagable.

In a "grasping at straws" effort, I created a small python script which basically just converts EVERY 32 byte sequence in the file into a private key (stepping through 1 byte at a time)... it generated 8999 private keys from the OP's "wallet" file!!!

Alas, even after they imported them all into Electrum (1000 keys at a time into 9 separate wallets), no BTC or transaction history was found.

I can only conclude from this, that the wallet is so badly corrupted that no private keys can be recovered from this file (at least, not without some major "magic" )

If you're referring to this wallet: https://play.google.com/store/apps/details?id=de.schildbach.wallet

Then, as far as Android/Mobile wallets go, it can be considered "safe"... insofar that it isn't a scam wallet that will steal your coins. However, the caveat of "don't put any more BTC in a mobile wallet than you would carry cash in your pocket" still applies.

No, it won't work... because you still won't have the private keys in your wallet to be able to spend the coins. Even though you could manually create the transaction, you won't be able to sign it (because the private keys are not there), so you won't be able to broadcast it to the network.

If you have already done a "reindex" and/or "rescan" then it's most likely that the file is corrupted or has been tampered with. In either case, there is no chance you will be able to recover any coins