The problem is with blockchair API that is rate limiting your IP address.
This is the link that's being called: https://api.blockchair.com/bitcoin/addresses/balances?addresses=1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa,12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX
If you click it with the same IP, you should see the error message saying

You can go to settings window (F2 shortcut) and change the API used for updating balances.

No because this tool doesn't keep an open/active connection. It has to be manually updated.

Some block explorers API services offer a WebSocket service that can track address(es) which can be added but I'm afraid they offer very limited rates to force people to purchase their subscription. Meaning it may be a wasted effort.

My plan is to implement Electrum protocol and then use it here as well. It could take some time since I'm stuck trying to finish other stuff in my Bitcoin.Net library.

I don't really know, sorry.

I'm happy to announce the newest version of one of my oldest projects (almost a decade old!), version 4.0.0



We've upgraded from the obsolete dotnet framework 4.7.2 to the new dotnet 8 and merged all project files into one. We've also moved to Avalonia UI so that the wallet can be used on all operating systems (compiled binaries are published for Windows, Linux and Mac).

The UI is also changed with the additional some cool looking icons. Before

Some dead API services were replaced but WatchOnlyBitcoinWallet is still the same light tool as it has ever been...

Bitcoin.Net version 0.27.0
[Full Changelog]

• Intruducd a new SPV clint (can sync headers for now, fetching history and UTXOs need more work)
• Add new properties to (I)Chain to let the user get header count, header tip and be notified of new blocks
• PoW rules are updated for TestNet3 and RegTest
• Introduced TestNet4 (BIP-94)
• [BreakingChange] Everything containing TestNet including NetworkType is renamed to TestNet3 for clarity
  
• DNS seeds are now part of the Constants
• Add some new and useful methods to mnemonic and path related classes
• Some bug fixes and code improvements

Denovo version 0.8.0
[Full Changelog](https://github.com/Autarkysoft/Denovo/compare/B0.22.0.0...B0.27.0.0)

• Upgrade dotnet to 8.0 and Avalonia UI to 11.x and of course the new Bitcoin.Net
• Significantly improve TestNet miner to handle both v3 and v4 networks and allow user to set CPU core count and enter transactions to be included in the block being mined
• Introduce a MessageBox
• Some code improvement and cleanup

Version 0.13.0 released

• All packages are updated (that updates UI, Bitcoin.Net backend and fixes some bugs and improves performance)
• Upgrade to dotnet 8.0
• Code is improved and cleaned up
• Dead API was removed
• Moved error message textbox to a better place to be more visible and readable

Binaries for 3 operating systems are published like before.
https://github.com/Coding-Enthusiast/SharpPusher/releases/tag/0.13.0.0

Sorry for my lack of activity. My life has been getting increasingly complicated over the past year or two.

---

Version 0.20.0 (2024-11-13)
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.20.0.0

• New feature: new copy and paste buttons for all search-spaces to be able to copy over lists
  
• New feature: recovering encryption password used for bitcoin core wallet.dat files
  
• Some bug fixes and code improvements

You are absolutely right!

I tested it and IV is not needed. Even went through the dotnet source code and realized IV that I was setting wasn't even used. When this calls this the IV is set to null!
For some reason in my initial tests when I was first implementing this, the code only worked when I set the IV (I wasn't aware ECB mode doesn't use IV). Probably because I was changing more than one thing at a time... silly me...

Here is my implementation of it as part of The Finder Outer (you missed the AES IV by the way):
https://github.com/Coding-Enthusiast/FinderOuter/commit/5063a1ec3038523db3031ef5efe14bdb6c82c5a0

All that's left is to add the UI element and add an example for it.

You don't need the overhead of a SPV client if all you need is to push a tx to the network. You can do it with much less. Feel free to check out my project Bitcoin.Net and its MinimalClient. There is a UI for it too which you can follow here:
https://github.com/Autarkysoft/Denovo/blob/master/Src/Denovo/ViewModels/PushTxViewModel.cs

I wouldn't recommend using it for wallet generation at the moment since I've been changing the ECC implementation and it might not be the safest option.

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

The behavior of the method and where it is used doesn't seem to have changed
https://github.com/bitcoin-core/secp256k1/commit/5b32602295ff7ad9e1973f96b8ee8344b82f4af0#diff-6e0cae0111d7c054ba27f22399eb4a2ac6c9788ee97da7f9fc5948c63dcf882c
However this "assumption" that the secp256k1_fe_set_b32_mod reduces the result has.

Am I missing something or is this a mistake?

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 this transaction 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 usage of 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.

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.

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.