Yes. If you don't specify it in the command line, then a pop up will ask for it.

No, two would be the minimum. You can't use one since one can't be compared to zero others, but you could use two with ^r1^ coming somewhere before ^r2^.

Note that with relative anchors (but not fixed anchors), you can use the same relative anchor on multiple lines. So if I had one line with ^r1^, and two different lines both with ^r2^, then both of the ^r2^ lines would come somewhere after ^r1^, but in either order.

As I say, it all depends on the format of your tokensfile, how many lines there are, the possibilities on each line, how much descrambling might be needed, etc. It also depends on how many guesses per second your hardware is capable of. If you share your tokensfile with the actual words redacted (feel free to PM it to me if you would prefer), I can do some rough math to work it out for you.

If you run without --no-eta, then it should calculate it for you, but in my experience this doesn't really work very well for large numbers and tends to just freeze up.

You just have to copy and paste the quote tags multiple times around each section of text you want to quote.

Not necessarily. If you've made more than one account under the same passphrase, then it could be m/84'/0'/1' and so on.

If you are searching using the xpub and --mpk, then you don't need to set an address limit anymore.

After entering the command (btcrecover.py --tokenlist tokenfile.txt --no-dupchecks etc. etc.) there are 2 popups: 1 asking for the xpub, the second for the seed phrase. Is this the same as the --mpk command?


No, that would be the case if you were using fixed anchors rather than relative anchors.

Fixed anchors (^x^) place that word in a fixed position. Relative anchors (^rx^) place that word in relation to other relative anchors.

If you use ^3^Word3, then Word3 would be the 3rd word.
If you use ^r3^Word3, then Word3 would be placed somewhere between the words you set as ^r2^ and ^r4^, but there could be other words between them as well, and ^r3^ wouldn't necessarily be the third word.

Is 3 words the minimum number of relative anchors needed to be used for this function?


It's all going to depend on the size of entire tokens file. But if you change the number of possibilities in a single line from 1 to 2, then that is going to double your search space. Change another line from 1 to 2, and the will double it again, so 4x in total. So even a few extra possibilities can dramatically increase the search space.

Again, it depends on what exactly you are searching. If you know all 12 words exactly but have them in the wrong order, then that's 12! = 479 million possibilities. If you know the order of 12 words, but each word could be one of four possibilities, then that's only 4¹² = 17 million possibilities. It will all depend on exactly how much you know and how much is unknown.

Brute-forcing 100 characters will never ever succeed. You'll probably have a very hard time with 10 characters already, if your password is that long your only chance is to remember (most of) it.

FinderOuter is great tool/software and more user-friendly. But with lack of GPU support, btcrecover is better choice on most cases.

I don't have computers with GPU so could give it a try. In FinderOuter where should I enter the words I think they are? Is it in "CustomChars"? If yes, do I put Word1Word2Word3 and it will try all the combinations from that?

Almost. Take the fresh address it path it shows you under your xpub and knock the last two sets of digits off it to get the derivation path for your xpub. So if it shows m/84'/0'/0'/0/5, your xpub's path will be m/84'/0'/0'. Make sure to include the ' symbols, these are very important and will generate entirely different keys if you miss them out.

The last thing to be sure is that this xpub is definitely coming from the account protected by the passphrase, and not from the base account with no passphrase.

If the order is off, then you are really going to struggle. Based on your initial post of 15-20 words, and the fact that I can descramble 12 words in a little under an hour, then 15 words would come out at around 100 days and 20 words will be in the region of hundreds of thousands of years, even assuming you were 100% correct with all your words and symbols.

So, assuming you know the order, then I would try something like this initially:

And so on.

The ^x^ before each word fixes the position of that word. btcrecover will then take one entry from each line and assemble that in to a passphrase in that order to try. So on each line, you put every possible permutation of that word. This is also assuming no spaces between the words.

If that fails, then change your tokens file to all caps.
If that fails, then take your second wordlist (e.g. veg instead of fruit) and follow the same process.
If that fails, then combine your wordlists and follow the same process.

Note that if $ is the last character of a token, you will need to replace it with %S otherwise btcrecover will interpret it as an end anchor.

In terms of the numbers at the end, you can do what you are doing and put every possibility on a single line with $ at the end, or you can use a wildcard if you are unsure about the numbers. For example, %3,4d will try every 3 and 4 digit combination. Note that this will significantly increase your search space, however.

How did you export the xpub? If you are sure it is correct, then you can just use that directly instead of then deriving an address from it. Your search will also be a little faster using the xpub since btcrecover does not have to derive one or more addresses for each attempt.

I followed steps 1-3 from here: https://support.ledger.com/hc/en-us/articles/6275459128989-How-to-analyze-a-Bitcoin-BTC-account-xPub?support=true

Instead of using the --addrs argument, replace it with --mpk xpub6ABC...
If you also know the derivation path for that xpub, then include the following as well to narrow down the search further, replacing xx with the relevant numbers:

That's the tricky part; not sure how to find the derivation path. Is the "fresh address path" (shown in the step 3 image from the link above) the same as the derivation path?

If you can give us much information as you know about your passphrase (obviously without revealing the actual words), then we can try to optimize things as much as possible.

Separate runs. There is no straightforward way to tell it to change the case of your entire token file.

You can put multiple tokens on a single line, and it will only try one from each line, such as:
However, there is no way to say "If you pick the lowercase token from the first line, pick the lowercase token from all the other lines too". So you will simply have to make a token file with everything in lowercase, and once exhausted change everything to uppercase, and so on.

If you are certain a word appears somewhere, but you don't know where, then use +
If you know the exact position of a word, for example "This is definitely the fourth word", then use + ^4^
If you have three words you think WordA comes first, WordB somewhere later, and WordC later still, then you would use something like this:
This fixes these word positions relative to each other. WordB will never be tried before WordA, but there could still be other words between WordA and WordB.
If you have three words and you know they are consecutive, then combine them in to a single line like this:
The %s will be replaced by a single space.

Combine these on the same line to try only one of them at a time. Example:

• The "address limit" tells btcrecover how many 'address_indexes' to derive (address_index starts at '0'),
  so if you're not certain of your address' index, better leave it with higher or default value.
  But if you're absolutely certain that it's the very first address that you've derived (not just the first to receive bitcoins), then '1' is enough.
  
  Is there a way to find out whether it's the first derived address or not? I do have the wallet in my Ledger desktop app. I also have the xpub but wasn't 100% certain I got it the correct way so thought using the address would be better.
  
• You'll be providing it with your address with --addrs so why do you have to provide the format?
  Anyways, --skip-uncompressed can be added to skip searching from uncompressed pubKeys which Ledger doesn't support.

I think I read somewhere that it searches all the formats and stating the current format will reduce the search parameters. Perhaps that's been updated in the latest version?

Yeah it runs offline mate just go to https://github.com/sc0tfree/mentalist/releases/tag/v1.0 and download Mentalist-v1.0-OSX.zip


Also running something offline doesn't always make it secure, this is a protip. If you want to be extra safe, Run this on a live usb or an old laptop with the network device removed &/or disabled from the bios.


Malware can aggregate data offline for posting it out later on, also crash reports, memory persistence happen too.

Download Mentalist from https://github.com/sc0tfree/mentalist

It's an amazing tool, easy to use and helps you build a custom wordlist.

With btcrecover you can load the wordlist with the --passwordlist command (afaik),

with mentalist can use the GUI and have a better understanding of how large the wordlist will also be.

The mask options have been confusing for me in btcrecover, it does a good job at checking if the password is correct most of the time but the wordlist is better generated with mentalist.


You also mentioned macbook, best thing to do is export all the passwords from the keychain and create a wordlist with them.

You might also want to check the better branch of btcrecover it's over at https://github.com/3rdIteration and the maintainer has great videos at https://www.youtube.com/@CryptoGuide

There is another tool that you can use to brute-force the wallet passphrase it was developed by Coding Enthusiast.

You can check that tool from his thread below

- https://bitcointalk.org/index.php?topic=5214021.0

Once you downloaded it just go to Missing Mnemonic Passphrase and try to brute-force your wallet just make sure that you remember some parts of your passphrase to speed up the process.

I'm sorry to read that you lost access to your bitcoin.

However I'm not sure that I fully understand, did you lose the seed phrase associated with your ledger?
As far as I know, ledgers have a code with X digits, not a password in words, right?

Can you tell us which wallet you used when you created your password?
Normally your seed should be 24 words long, if you didn't add any. If your wallet was Electrum for example, then your seed phrase would only be 12 words.

Btcrecover is a great tool, as hashcat is too. But I am not sure to understand enough your exact problem to be able to advise 1 specific tool

Good luck with your coins!

1.1 billion again and it's hung up badly but started up again after an hour. Didn't get the process kill code yet but I got a feeling it's coming. Gonna let this play out and see what happens but I think this is it for me on this angle. Gonna have to get a better setup before trying again but at least I know I got the winning formula, just need the right tools to work it out.

One thing of note. While getting to 1.1 billion, it seems to have been running off the RAM because the 6 disk raid array were not blinking. Ever since the hangup, it's running much slower with less results and all 6 disks are blinking like it's Xmas.

Maybe I'll be back in a month or so. Thanx to everyone who contributed. For now I may be beaten, but I'm far from defeated.