The option is found under "Missing mnemonic" and you have to select the "Electrum" type from the second drop  down on the right, then select the wallet type that Electrum was using from the drop down that appears after that. Make sure to enter the correct BIP32 path. Example 6 and 7 are Electrum mnemonics missing 1 and 2 words respectively.


A couple of points:
* Electrum mnemonics are 12 words by default
* You have to know the position of the missing word. But if it is only 1 word you can manually change the position from start to end and click Find 12 times, it should all take 12 seconds.
* You have to know a derived child from that wallet (it can be a child private key, public key or an address)
* Setting the path correctly is very important. When setting the wallet type (Electrum mnemonic type) FinderOuter automatically sets the correct path for that type but you have to enter the index of the child key you entered (eg. if you entered the 10th address you have to add 9 to the end of the path)

That's fantastic. I'll have to go back to check Pollard's kangaroo algorithm again.

Interesting approach but what's the speed of something like this?

And how does it perform compared to the simple approach of decoding and computing checksum that only computes SHA256?
For example it takes me 3.5 min to check the entire 656 million keys in your first example using checksum (answer is found after 1.1 min) and it is faster if the key was compressed (KwQ4QV73DpTafe_____MfTTgNH2z78JVPqEegga2ovWATXzDVu6U) only 25 seconds.

You're welcome.

If you mean something similar to the "puzzle solving" projects where they go from 2ⁿ to 2ⁿ⁺¹ to find the private key to an address/pubkey then I don't think I'll ever add such an option to FinderOuter since the purpose of this tool is to help users recover their coins not to solve puzzles.
But in some ways FinderOuter is essentially doing the same thing (although it needs more optimization), each option with a missing base58, base16 or mnemonic is searching within a fixed range.

I also have a plan to let the user limit the search space if that's what you meant. For example in mnemonic recovery user would be able to set a smaller range of words (like 5) to set in place of a particular missing word instead of using the entire 2048 words. This requires some major refactor so I'm putting it off for now.

Version 0.7.0 is released.
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.7.0.0
See changelog for details.

• General user interface improvements
• AvaloniaUI is updated to version 0.10
• Progressbar now shows the progress percentage
• A warning is added to MainWindow to inform those who build from source and forget to use -release (ie. if they run FinderOuter in Debug mode by mistake)
• Menu (help and about windows) is removed
• Examples are improved, some new ones are added and the button is now showing the count and current example index
• Recovery option descriptions are slightly improved
• Fixed a bug in mnemonic recovery option when user entered a mnemonic with no missing words

---

Single SHA256 of the passphrase while enforcing a minimum 15 character length passphrase.
https://github.com/pointbiz/bitaddress.org/blob/72aefc03e0d150c52780294927d95262b711f602/src/ninja.detailwallet.js#L58-L62

It is insecure so if OP has some idea about the passphrase they used there could be a chance to brute force it rather easily.

Each data (byte array) that is to be pushed to the stack (in the scripts) is preceded by its length. For example if you want to push bytes {1,2,3} the script you use the length that is 3 followed by those bytes: 0x03010203.
If the the data can be converted to one of the predefined constants then that constant should (in context of standard rules not consensus rules) be used instead.
For example if you want to push {5} then we have a constant for it called OP_5 which should be used instead. Meaning instead of using 0x0105 we use 0x55 (which is equal to OP_5). That way there is no push length anymore since another OP code was used.

AFAIK these OP codes existed from the beginning and weren't added later. In fact there are a couple of ways that bitcoin encodes numbers (CompactInts for instance) and they all support huge values.

It is "cleaner" to have all data push OPs in one place without any space between them. If we wanted to add that in the future it would have been >= 0xba instead of right after 0x4d (OP_PushData2). Besides we already have 70 free unassigned OPs (from 256 possible ones in one byte) with a bunch of NOPs and some removed/disabled OPs so assigning a never used OP code such as OP_PushData4 is not really a big deal.

It is "up to" 2 bytes. It can be 0, 1 or 2.
For example it could be OP_Return OP_2 (which passes IsPushOnly()).

All data has to be pushed with its appropriate size byte(s).
* Any bytes that can translate to a number should use OP_number ({0} should use OP_0 instead of 0x0100, {16} should use OP_16 instead of 0x0110)
* Any bytes with lengths smaller than 0x4c (76) is pushed with 1 byte equal to the size (byte[10] -> 10 + byte[10]; byte[70] -> 70 + byte[70])
* Any bytes bigger than or equal to 0x4c is pushed by using 0x4c (ie. OP_PUSHDATA) followed by the length followed by the data (byte[80] -> OP_PUSHDATA + 80 + byte[80])
* Any bytes with length bigger than 255 uses 0x4d (OP_PUSHDATA2)
* Any bytes with length bigger than 65535 (0xffff) uses 0x4e (OP_PUSHDATA4)

This is the correct one.
Data length is 4 bytes and 4 is smaller than 76 so 0x04 is used as length followed by the data itself.

As for converting "2021" string to bytes, bitcoin doesn't care what is used, UTF8, ASCII, Unicode,... it is up to the extra protocol (like the side chain) or the user's preference to decide. For instance you could use Unicode and convert emojis to a byte stream that you push after OP_Return.

Yes.

I don't know much about UTF-8 but I don't think there is such thing as "1 byte UTF-8".
AFAIK the way this encoding works is that you read one byte at a time and decide based on that byte how many more bytes you need to create the first character.
For example if the first byte is 0xxxxxxx (in binary where 0 is zero and x can be 1 or 0) then that byte is the character itself.
If the first byte is 110xxxxx (in binary) then you have to read another byte and the two bytes represent the character (the second byte also has to use 10xxxxxx format).
Similarly 1110xxxx for 3 bytes and 11110xxx for 4.
That means you can end up reading 4 bytes from the stream to be able to represent 1 character (0xF0, 0x90, 0x8D, 0x88 -> 𐍈 Hwair since the binary is 11110000 10010000 10001101 10001000)
You can check the Wikipedia link https://en.wikipedia.org/wiki/UTF-8#Encoding

Or here is the .net source code in C# where it converts the bytes to string when it can't be mapped 1 byte to ASCII chars: https://source.dot.net/#System.Private.CoreLib/Utf8Utility.Validation.cs,250

2&3. Size limit is a standard rule and it is 83 bytes. 80 bytes of data, 1 byte the OP_Return itself and 2 bytes for push data byte(s).
https://github.com/bitcoin/bitcoin/blob/bd6af53e1f8ec9d25cedf0bf36c98b99a8d88774/src/script/standard.h#L96-L99
There is no limit in the protocol for output script size or even validity including OP_Return outputs. Here is a transaction on testnet with 93 byte OP_Return e598de457ebda1638730062efddd9a45d2bc14efb20a5acc83771eed0799f3f59
Here is another one with 542 byte size 7d2922f0b0ee315e7fd0a5f2ba702ee7bfc613cca3dd23cebe52c5aa45609d6c
And another one with 10004 byte size 9b333e6043490472f8e4351008acdd3d16ffce7a90043dc9ebcf1b1739a7cc20
(I have more test vectors with invalid scripts if you're interested)

4. As far as the protocol is concerned you can include as many OP_Returns as you like since they are just output scripts and there is no limit on txout count (except the block size).
As far as standard rules are concerned any transaction (obviously except coinbase) is limited to only one NULL_DATA aka OP_Return output.
https://github.com/bitcoin/bitcoin/blob/4a540683ec40393d6369da1a9e02e45614db936d/src/policy/policy.cpp#L132-L136

6. It depends on the block explorer, but I usually see them use UTF8.

No.

That is not a problem that a "recovery tool" can solve.

Of course it does. Example for 24 words

It is because the slowest part of the code is SetBip32(...) method and it is only called when the checksum of the created mnemonic is valid. When we call it less times, the speed is going to be a lot higher.
The number of times checksum is valid depends on the size of the checksum, the bigger it is the less collision occurs and SetBip32() is called less times.
A 12-words BIP39 mnemonic only has a 4-bit checksum while a 12-word Electrum mnemonic has at least 8 bits of checksum (8 bits for standard type, 12 bits for other types).

Back to our 5^th example

                   SetBip32() call count         time
BIP39                    261,774                00:02:44
Electrum-Standard         16,464                00:00:12
Electrum-SegWit            1,064                00:00:02
Electrum-Legacy2FA         1,057                00:00:02
Electrum-SegWit2FA         1,015                00:00:02

The reason why the last 3 numbers are slightly different despite having the same checksum size is based on luck.

Not that I know of.

There are too many unknowns here. You have to try and narrow it down.
For example when you say "years ago" how long are we talking about? Was it before 2017 or after? Coming up with a year could eliminate certain BIPs (derivation paths, address types,...).
Could you remember anything about the wallet you used to create these words? Best thing would be the name of it but the type could also be helpful, a phone/desktop wallet or though some website, a web wallet like blockchain.info or some custodial web wallet? Because the words you have may not even be a mnemonic.

LOL!

I've been trying to absorb all my old projects into two new projects which I started in 2020 but it's been a lot slower than I anticipated, mostly because I keep working on other parts and keep postponing it.
There is an open issue about it on both projects: https://github.com/Coding-Enthusiast/SharpPusher/issues/3

I believe I told you about the "MinimalClient" in Bitcoin.Net. It will be used for doing stuff like this. It will connect to a random full node the same way any other full node finds and connects to other nodes (DNS seeds or the local database it creates for subsequent connections) then it will perform the handshake and sends the tx message. There is no need to do it with more than one node but it is possible.

I believe your CPU is slower than mine but the main reason is that you are adding bottlenecks that are significantly slowing down the application.
First and biggest one is that you are running it in Debug mode which doesn't have a lot of the optimization. Switch to Released mode and you will experience a much faster run.

Additionally when you run any application through V.S. it automatically attaches a debugger that will consume some CPU power and can slightly slow down the application.
If you want to run it without V.S. then you either have to install .net or publish the application. Here is a walk-through: https://docs.microsoft.com/en-us/dotnet/core/tutorials/publishing-with-visual-studio

Is your CPU older than mine? Or are you running FinderOuter in some sandbox/virtual machine that could limiting the CPU usage?

If in example 5 I switch BIP39 to Electrum and change the path from m/0 back to m/0' then it only takes 11 seconds to check all combinations.

Whenever there is an "additional info" textbox in any of the recovery options, the result is always checked against that and the loop will break as soon as the comparison was successful.

Each depth adds another round of HMACSHA512 and some small math for all index types, but also adds another EC point multiplication if the index wasn't hardened.
For example m/0 only performs one additional EC mult and one HMACSHA512 compared to m/0/0/0/0 which has to perform 4 which makes it 4 times slower.

Have you tried the 5^th example? Just click on Example button 5 times, and it should only take a minute to solve.

Sorry I should have asked about your path first, BIP39 recovery speed depends a lot on the path, doubly so in my code that has a known issue with ECC.
Generally speaking the shorter your path is (eg. m/0 vs m/0/0/0/0) the faster the recovery.
The more hardened indexes the path has (eg. m/0'/0'/0'/0' vs m/0/0/0/0) the faster the recovery.
Additionally when the path is using hardened indexes it avoids the issue in FinderOuter so the speed goes up by a lot and it can also use the all CPU cores.

To compare your PC speed with mine in the most optimal case check out the fifth example. On my corei3 CPU it barely takes 3 min (0:02:40) to check the 4.1 million cases.
https://imgur.com/a/uRHbDef

No. UI isn't consuming that much CPU power, it is just a thread that will be updated every now and then.

Not yet.

10 words out of how many? 2 missing out of 12 takes only an hour on my old PC, having 10 out of more like 24 is impossible to brute force.

It will stop as soon as it finds the correct combination of words and prints the result.

As far as I can tell the only way to download blocks from another peer is through using getdata messages (is there any other messages?) which have a limit of 50000 items; but there is also MAX_BLOCKS_IN_TRANSIT_PER_PEER (=16) which I'm not sure what it's used for.

My getdata requests with 17 inventories are ignored sometimes which has left me confused. I'm not sure if it is the limit on number of blocks I can request or if it is fPauseSend which will then erase the m_getdata_requests completely here which means the request is ignored entirely.