Version 0.19.1 (2024-01-24)
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.19.1.0

• Fix a bug in VMs where FinderOuter crashed if user entered an invalid input
• Move to .net 8 and compile binding (UI)
• Some cleanup and UI fixes

This minor release is fixing a critical bug but also moves to the new .net 8 which required changing UI bindings to compiled binding to prevent UI code from being trimmed. This also further decreases the binary sizes (~8%).
The backend (Bitcoin.Net) is also updated to 0.26.0 with improvements and bug fixes in ECC implementation which should also bring some small optimization.

I think it is best to address all shortcomings of BIP39 when proposing a new algorithm. Version only addresses one of them. I tried to address some more in my rough idea a couple of years ago: https://bitcointalk.org/index.php?topic=5330229.0

I'm going through libsecp256k1 and noticed a new change which is strange.

secp256k1_fe_set_b32_mod method name and comment suggest that it reduces the value mod p and the result is supposed to be r ≡ a (mod p)
https://github.com/bitcoin-core/secp256k1/blob/c1b4966410a81162bf9404ec84e69a85e1e23469/src/field.h#L192

But looking at the implementations they don't actually perform any reduction. It's just a simple conversion from byte[] to uint[] in radix 26 or 52.
For example:
https://github.com/bitcoin-core/secp256k1/blob/c1b4966410a81162bf9404ec84e69a85e1e23469/src/field_10x26_impl.h#L293

How the method is called(?):
https://github.com/bitcoin-core/secp256k1/blob/c1b4966410a81162bf9404ec84e69a85e1e23469/src/field_impl.h#L258

After this commit the library seems to still use the old method (secp256k1_fe_set_b32_limit method so I don't think anything is changed there) except here
https://github.com/bitcoin-core/secp256k1/commit/5b32602295ff7ad9e1973f96b8ee8344b82f4af0#diff-6f71b0372be086d45b4f2740508c03a21835d87008840032fbb767f419fd988a
And this "assumption" that the secp256k1_fe_set_b32_mod reduces the result is new.

Am I missing something or is this a mistake?

Edit: fixed in https://github.com/bitcoin-core/secp256k1/commit/77af1da9f631fa622fb5b5895fd27be431432368

This is one of those little details in Bitcoin that not that many people know.
The only OP codes that would invalidate a script by just existing are these (like OP_CAT). However, OP codes like OP_RETURN need to be executed to invalidate a script, otherwise they can exist in an unexecuted branch for example and the script would still be valid.

Example:
https://blockstream.info/testnet/tx/95b3bccdd66d139f7f87a6c85bb704cb7278bfb8f8ff1859e3c9f99223c3bcc4?expand
The redeem script here is:
The output was spent using the IF branch
Since the OP_RETURN is never reached or executed, it does no invalidate the script or the transaction. As you can see the transaction I created was included in testnet block #2540377

Version 0.19.0 (2023-11-15)
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.19.0.0

• Add settings to define the number of threads used in parallelism + KB entry
• Old Electrum mnemonics are still not supported but they will be rejected with a clear message
• Various bug fixes, code improvements, additional tests and some UI fixes

Two major changes in this release are migration to the new Avalonia UI version 11.0 and .Net 6 with trimming option that reduces the binary size by roughly 40%. Even though most UI bugs were fixed before releasing v0.19 there may still be some uncaught ones, please report them on GitHub (or here) if you encounter any.

Thanks for the link, that's very useful.
For the sake of comparison the speed I reported above is using i3-6100 CPU with 4 threads.

That's embarrassing I must need some coffee too...

Isn't 115 minutes (at best 1.1k permutation/sec) too slow?
Although FinderOuter doesn't have this feature but I get 22k perm/sec for BIP39 and 1.2m perm/sec for Electrum mnemonic on CPU when recovering 12-word mnemonics with missing words.

https://github.com/Coding-Enthusiast/FinderOuter/commit/09466f3e9fe2b57fa158c1f61add98e15cb6973d
This was added under an expander on the side with the name "Settings" that will allow you to set the number of threads the parallel loops use based on the number of cores .net can detect.
The max value here may not be accurate in case the system has more than one processor group or has CPU utilization limit. I'll probably add an override option to go beyond that limit as a more advanced feature since going beyond the thread limit could potentially slow down the process.
This also needs some guides on how it should be used etc. in our KnowledgeBase page which I'll add before v0.19.0 is released.


PS. If you build at the given commit above, know that there is currently a bug in our UI where the slider appears to be at the minimum value (1) when the application starts but the actual value is set correctly to the maximum number of threads. This is fixed in the new AvaloniaUI 11.0 which we need to upgrade to but it takes time due to the breaking changes in the UI framework.

Sorry for the late reply.
When you want to modify the search space you have to set the whole space for each missing position but it is easy to set the other positions to "All" by only pressing a button and only limit what you want by manually adding characters or removing the extra ones.

For example lets say we want to recover these two missing characters in "L53fCHmQhbNp1B4JipfBtfeHZH7cAibzG9oK*9Xf*FzxHgAkz6JK" and you know the first one looks like "1" but you have no idea what the second one is. After clicking "Start" (to process the key and initiate the arrays) you enter "1" in the textbox and press "Similar letter" button so the list can be populated with "1" and "L", then you can continue modifying this list by adding or removing characters if you don't like the suggestions.
Then you move to the next position by pressing the ">" button and repeat the same thing. Here you simply click the "Add all" button to populate the list with all 58 characters.
When you are done setting the search space you finally click Find.

For now until version 1.0 I'm focusing on increasing my test coverage and finding bugs while improving the printed reports and messages.
After that I'll start investigating how to add GPU support.
Anything else I'll try to squeeze in if I have any idea of how to implement them efficiently without needing any significant code change.

The feature to limit search space when recovering Base58 inputs was added to FinderOuter in version 0.15.0.

Version 0.18.0 (2023-06-23)
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.18.0.0

• Improve the returned message (errors and reports)
• New feature: time estimation. Addresses #30 [1]
  
• New feature: Add an AutoCompleteBox to mnemonic recovery option to suggest words based on letters the user entered [2]
• Various bug fixes, code improvements and some additional tests

---

[1] This will show the number of keys that were checked so far and an estimated speed in number of keys(permutations) per second and the estimated time remaining until the entire search space is checked. Note that in most cases the actual key could be found before the entire space is searched.
See issue #30 for information on its limits.


[2] When modifying the mnemonic search-space by entering possible words, user can switch to the Auto Complete mode so that a suggestion list opens up based on the letters that were entered so far. This should also make it easier to see all words that contain certain letters (like the image below with words containing "xi").
Mode can change any time using the switch button.

Almost all the code used in FinderOuter is heavily specialized to perform special tasks required for recovery. Considering how it doesn't have a recovery option for brainwallets, it is not useful for OP. (I haven't seen any demand for brainwallet recovery option to add it to FinderOuter)

If you want general implementation of different algorithms like SHA256, ECC, etc. my library Bitcoin.Net is more useful.
Although I should add that if the goal is to "recover" a brainwallet, any "general purpose library" is very inefficient.

Under releases on GitHub there is always a zip file containing the binaries for Windows.
https://github.com/Coding-Enthusiast/FinderOuter/releases/download/v0.17.0.0/FinderOuter-0.17.0.0-Win64SCD.zip

As for your other suggestions, manual key generation doesn't really fit into a "recovery tool" so it can't be added to FinderOuter.

These days we are witnessing my concerns from 2 years ago materialize in form of a mess called Ordinals. It is a good example of the downsides of leaving consensus rules this loose for extensibility purposes.

I'd say roughly 1-2 hundred millions of addresses can be encoded sequentially this way per second per core. Although since we are talking about 10¹⁶⁰ addresses, the size is going to be massive and won't fit in any memory or storage space.

We are heading for the first stable version (v 1.0) by fixing as many little bugs as possible and improving the code in general. Since that may take a while I'll try to publish more beta versions that act as pre-releases to 1.0 from now on. As always follow the roadmap to see updates on when new features like GPU support could be added.
Here is version 0.17.0 with lots of little improvements:

Version 0.17.0 (2023-02-27)
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.17.0.0

• Removed message signature verification
• Solve issue #4 (not being able to enter words in CJK languages)
• Completely rely on new Bitcoin.Net release for ECC (has some bug fixes and slight optimization)
• Improve printed messages (errors and reports)
• Improved how Base16, Base58 and MiniKey options handle configuring search-space which solves some bugs and returns better messages
• Return a comprehensive message when an input contains invalid characters (the invalid char and index)
• Small UI improvements
• Various small bug fixes, code improvements, code cleanup and lots of new tests

PS. FinderOuter is 3 years old

Bitcoin.Net version 0.23.0

• Replace old ECC with the new implementation
• Disabled BIP-137
• Small code improvement and bug fixes

No Denovo released this time to keep the binaries on the old Bitcoin.Net version. You can build master branch since the code is updated.

Everything is already explained in ReadMe file. If you have the source code and want to compile Step 2 or Step 3 if you have the complied binaries and want to run.