Considering that with recent changes the full nodes and miners are starting to accept transactions with fees that are lower than the standard 1 sat/vb, we needed some way to actually push transactions with fees. lower Some APIs are still rejecting them but mempool.space API appears to be the more reliable endpoint we can use which is why it was added in this release.

Of course our P2P option (pushing directly to a full node) can also be used but the problem is that full nodes don't return any messages if they reject that tx. Our implementation also doesn't currently have the option to "filter" out what nodes we want to connect to. I have some ideas I will investigate at some point (eg. is feefilter message reliable?) and try to improve stuff.

Version 0.14.0 released

• Added mempool.space API to allow broadcasting txs with fees lower than 1 sat/vb
• Removed some unused/dead altcoins
• Utilized trimming more to get smaller binaries (60% smaller)

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

This tool only runs on desktop so I first have to add the UI stuff for it to run on smart phones then put it on such websites. And that's not currently on my todo list.

The problem is with blockchair API that has blacklisted 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 implementing 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...

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 pushing txs 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

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.