Let me do a little advertisement of my newest project here if you don't mind.
The project is called HandyDandy which focuses on stuff like this. It is essentially visualization of a bit stream that you can edit by clicking a button corresponding with each bit.

It works for creating a private key or a mnemonic and has 2 forms: a grid or grouped by 8 bits for private keys or 11 bits for mnemonic (each word is 11 bits). Each button has 3 states (?, 1 and 0) to help user keep track of which button they've already clicked and where in the stream they are.


I haven't started an announcement topic yet or release the binaries because it needs some more work focusing on the UI elements and some tests. But you can compile it yourself and have some fun with it.
Everyone is also welcome to contribute.

New Denovo feature:
You can now verify any transaction by manually entering the tx hex and all the UTXOs it is spending.

An example transaction from last block (7e975f265af0286cd5b6d355b7a92f89e5cdfa6f221ac5614efea57fcef268ba):

• This can verify any bitcoin transaction
• The first TextBox needs a raw transaction hex and it will automatically create a list of UTXO TextBoxes to be filled by the user (only amount and script are needed)
• The result will contain total transaction fee in satoshi and total SigOp count for valid transactions.
• The result will contain a reason for failed/invalid transactions
• Currently the used Consensus dependency has everything activated (will add more flexibility in the future to manually activate/deactivate any soft fork)
  
• Taproot is also activated but the verification may give false results since it is untested in current Bitcoin.Net version (v0.14.0)

I took the liberty of starting a new issue based on this: https://github.com/spesmilo/electrum/issues/7483
Update: This is fixed in 07bd2fe.

You could always use Electrum protocol itself instead of the wallet software to connect to Electrum full nodes and get balance, history, etc. from them in a much more decentralized way which is also faster and free. I've been meaning to implement this (as an SPV client) in C# but my focus is being drawn to other projects so it keeps getting postponed.
Here is the doc: https://electrumx-spesmilo.readthedocs.io/en/latest/protocol.html

Very important because for each checksum that fails all the HMACSHA512 computation and the EC multiplication that comes next will not be skipped. For example for a 12-word mnemonic we only have to fully check 6% of the permutations on average.

Even with skipping this much by using checksum the algorithm is still very slow. For example for my recovery project I've been squeezing every ounce of performance that I could and I still can not reach half a million checks/second while at the same time recovering a WIF (which is essentially a double SHA256 similar to mining, ie. 2 blocks instead of 3) despite complexity of Base58 encoding goes as high as 60 million checks/second.

There is not enough incentive. We are talking about breaking a mnemonic that we know most of it, like a paper backup that was torn in half. How many cases of this is found out there anyways and how much bitcoin they've got locked up?

These two are not comparable. To mine a bitcoin block there is only 3 SHA256 block compressions while to brute force a BIP39 mnemonic in most optimized scenario it takes 1 SHA256 block compression, 4,101 SHA512 block compressions + 4 SHA512 block compressions per path index + 1 EC point multiplication per non-hardened path index.
For a path like m/44'/0'/0'/0/0 this is 4,121 SHA512 blocks which is 1373 times more than what miners compute and we are ignoring the EC point multiplication. If we assume the data could be extrapolated, it should at least take 10 days to 2 weeks not 10 minutes.

Another issue is whether we can actually build an ASIC that does all the operations needed to brute force a BIP39 mnemonic and more importantly if it can operate as efficiently as a simple SHA256 ASIC that repeatedly runs a much simpler algorithm.

That's another bad comparison. The "puzzle" is a puzzle and in that search one starts searching in a small private key space and only computes the corresponding public keys. When the corresponding public key is known certain "tricks" could be used to speed it up because of ECC characteristics.
In brute forcing an entropy on the other hand even if the child public key were known it still wouldn't give any edge to brute forcing.

Not exactly. Version 2 onion addresses were truncated (80-bit) encoding of 160-bit SHA1 hashes. SHA1 has been considered weak and broken for many years and cutting that hash by half makes it even easier to attack.
Version 3 also doesn't use a hash anymore it is encoding the actual ed25519 key.

For future reference:
You just have to check if the returned type is not Invalid (eg. wrong checksum, wrong length, etc.) or Unknown (eg. Bech32m with witness version 2+).

Bitcoin.Net has a huge number of tests that you could use as examples. Each test file is in the Test project with the same namespace name.
/Tests/Bitcoin/Encoders/AddressTests.cs

3 different network types are defined in Bitcoin: MainNet, TestNet and RegTest and some of the prefixes used when encoding addresses (and other variables elsewhere) are different for these networks.

There is no reason not to!

This is a very bad approach and will have a lot of false positives and false negatives.

• Address length in Base58 is not fixed. It may be as small as 26 and as big as 35 (the article uses wrong values).
• First character being 1 or 3 doesn't mean the address's first byte was correct. Eg. 3R2cuiTJNvFDn18H7i7h7pvwYuvaRTNaJq is an invalid address because it uses 6 as the first byte instead of 5
• Regex doesn't validate the address checksum for either legacy or Bech32
• Due to lack of checksum validation there is no way to reject Bech32 addresses for version 1+ witness programs
• Certain edge cases aren't considered such as "bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqyqskt8xg" being an invalid Bech32 address

The point I was making is that you can't know the script type that was hashed by seeing the address alone. In other words you can validate a P2SH address and get the 20-byte hash out but there is no way to tell from the address if the script type which is hashed is P2WPKH or P2WSH or a legacy redeem script or something else entirely (eg. P2TR-P2SH).

I have a library called Bitcoin.Net that has a static address class that does validation like this.
You have to use the GetAddressType method with 2 overloads
AddressType GetAddressType(string address, NetworkType netType)
AddressType GetAddressType(string address, NetworkType netType, out byte[] data)
This both checks the address and return its type and it can decode and return the data (hash) encoded by that address.

If you want to check the address against a certain pubkey script type you can use bool VerifyType(string address, PubkeyScriptType scrType, out byte[] hash) method.

BTW "nested SegWit" address type is P2SH, there is no way of having any additional information by only seeing the address.

Version 0.12.1 is released.
https://github.com/Coding-Enthusiast/FinderOuter/releases/tag/v0.12.1.0
See changelog for details.
This is a small bug fix in Missing mnemonic pass option where the first character of the founds passphrase weren't included in the final report.

Even worse is that sometimes a big percentage of the addresses returned by DNS seeds are not valid.
For example last time I was testing about 20% of addresses returned by seed.bitcoin.sipa.be were dead ends

Stay tuned for my new project called HandyDandy, it will focus on this type of things.

Almost all programming languages could be used as long as you are capable of writing secure and efficient code in that language.

I had a similar issue recently where I received a ton of useless IP addresses but since I check each received IP before storage, they never reached the disk. It just created a big queue of pings which mandated some code changes. Some silver lining.

I'm not familiar with wallet file passwords but it sounds like something that would also include AES.

To be clear the speed above is not just PBKDF2, it is PBKDF2 + BIP32 KDF including EC mult + child Private to Public key + RIPEMD160 & SHA256 Hash (for address address comparison) among other smaller things.

Although that's true but I have to disagree here. I consider optimization like above to be the least effective and only to be used in the "last squeeze" step when we want to get every last bit of performance.
In other words optimization does not start from the code or language, it starts from the algorithm. For example in this case it doesn't matter much if SHA512 is optimized any more than it is now if the "HMACs are simply called", instead we can modify the algorithm to easily double the speed by avoiding 4,096 block compressions out of 8,192 each round, and that's just part of it.

Thanks, that is very useful. I think the values can be converted.
From the looks of it this is brute forcing the passphrase assuming it consists of words (international+accessories+university), FinderOuter currently has only one option and it assumes your passphrase is a random set of characters (H?s=3) which would make a very small difference in my implementation; and the rest is the same. Basically how the initial data for inner SHA512 compression is set has to be changed to copy bytes from a predefined array (won't be expensive).

So the first picture here with corei5-3380 translates to 625 pass/sec and second to 1218 pass/sec. If my understanding is correct then I'm quite happy with my ~1500 pass/sec on corei3-6100.

The only thing I had to adjust was the BIP32 path which slows things down a bit since it has 2 extra indexes compared to my initial benchmark. I believe that ETH addresses are less expensive to compute since they use Keccak256 instead of RIPEMD160 of SHA256, ECC is the same since it uses the same curve as bitcoin.
17,576 pass in 12 sec is 1,464 pass/sec. The rate will be the same regardless of the passphrase length.

@ranochigo is correct, but the main reason for BIP38 slowness is using a much more expensive key derivation function called scrypt which also unlike PBKDF2 can't be exploited for optimization. On top of that the costparam of 16384 is meant to make it even more expensive.
For comparison, on an un-specialized code scrypt can generate 12 keys per second on my very old CPU. This also doesn't include AES and the extra steps of BIP38.

Although I haven't started on BIP38 option yet, I believe there are ways to optimize it. With a quick look at bip38-cracker project on GitHub the code doesn't seem to be "specialized" for this matter. Hopefully for v0.13.0.

If you have used any BIP39 passphrase (extra/extension words) recovery tools using your CPU please let me know what was the speed you got, preferably in terms of pass/second.

I recently added the BIP39 passphrase recovery option to FinderOuter and am now working on its parallelism, while testing the speed I'm getting a surprisingly low speed of 1500 pass/sec. Although my CPU is old and it is expected to see a very low speed due to the algorithm being "expensive" but I'm wondering how does this compare to other tools out there.
This is surprising because I'm already exploiting PBKDF2 weaknesses and reducing the work by almost 45% so I don't think there is that much room left for further optimization.

If you want other tools to check Electrum mnemonics feel free to check out my project called FinderOuter. It is a recovery tool but in most recovery options when you enter an input (like mnemonic or WIF) that is not missing anything FinderOuter will automatically validate it and report if it is a valid input or not.
The current version (v0.11.0) will fully check mnemonics against the given word-list and their checksum based on selected mnemonic and Electrum mnemonic type. I'll also add the extra step to check against the given child key in next release (v0.12.0).