Seeds, key derivation and wallet structure changed from 1.x to 2.x but did not change in 3.x. The version 3 Electrum introduces SegWit support hence the major version bump.

Check out https://github.com/gurnec/btcrecover I believe it has options you are looking for.

That simply is impossible since AES-256 (the encryption that Electrum uses) is a modern cipher which is resistant to known-plaintext attacks and it has been designed in a way to resist this type of attack specifically since in most use cases of it we already assume that the plaintext is known.

Since this project has been getting some traffic on GitHub and some clones I decided to prioritize it for now.

Added scrypt-miner for litecoin to only work with the algorithm and see how LTC mining works, it is not optimized at all. Also since every code I post is written 100% by me from scratch sometimes I end up with much faster code (SHA256 and HMAC are 60% faster than .Net framework's) and sometimes I end up with much slower code (scrypt). These functions are from the library I'm working on so they are thoroughly tested and they are all generalized instead of being specific to mining the 80 byte array!

https://github.com/Autarkysoft/LearnMining/commit/0dd1c4121e0aa8b0654ac1fe07df79efae9df118

I haven't decided whether to focus on optimizing this or move to CryptoNight algorithm since it uses AES among other things and I've already been working on that for my AEZEED project.

I've started a new project: https://github.com/Autarkysoft/LearnMining
It serves 3 purposes:
1. Helps with learning how mining works
2. It works with the hash algorithm under the hood
3. Explores optimization of code written in C#

It is a work in progress and I have written everything from scratch purely based on documentations without any kind of "code translation" or "code copying" from other projects so it might contain some mistakes.
Currently it only has bitcoin mining (double SHA256). But I plan on adding other hash algorithms, possibly Scrypt (what LTC uses) be next. I am open to suggestions.
The code has tons of comment on it and I believe it is easy to understand what is going on, I can add more if something is unclear.
Since this is obviously not meant for actually mining anything, parallelization is avoided and it works only on CPU.

Please check it out and tell me what you think. Specially the part about Target here and here, not sure if I'm missing some endian swaps there.

Actually I'm assuming you have to go through all of them multiple times not just once and the reason is because I keep changing the header and hash it with all nonces and don't get any results. For example as I said above if the block time was 1231470172 instead of 1231470173 no acceptable hash could have been found.
Obviously I haven't tested that many cases due to having only 1.7 MH/s with 1 core, to talk probability and this is just an assumption based on small number of tests.

You might be referring to the guesswork about number of coins Satoshi owns which also included an estimation of his hashrate. That put it around 7.16 MHS and concluded Satoshi must have had more than one machine mining bitcoin. https://organofcorti.blogspot.com/2014/08/167-satoshis-hashrate.html

BTW 7.16 still doesn't make sense to me because of what I explained before and since it takes 10 min to go through 4.2 billion hashes.

That is not "all" possible combinations. That is only all possible nonces. We go through all the ~4.3 billion of them and perform the hash, when we fail to find the result we want, then we change something else and start nonce from 0. For example in block #3 if you deduct 1 second from the time (the block time field) we won't find the hash we were looking for (smaller than the target).
So practically you may do this multiple times to find the correct result and my problem is that the numbers (according to hashrate) don't make sense.

I am having trouble with some numbers, they don't make sense!

Let's say it is 2009, difficulty is 1, you are mining with your Core 2 duo E7300 CPU (the CPU of that time [1]) which gives you a hashrate of 3 (rounded up from 2.52) MHash/s [2] to find block #3 [3]
Nonce max value is 4,294,967,295 and to go through a whole set of hashes takes:
4,294,967,295 hash / 3,000,000 Hash/sec = 1,431 sec = 23 minutes.

Block #3 was found in ~7 minutes which is the result of calculating 4,294,967,295 hashes more than once (since the nonce in coinbase was changed).

[1] https://www.computerhope.com/history/processor.htm
[2] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison
[3] https://www.blockchain.com/btc/block-height/3

You need to think back to the time when you backed up these words and remember what you did that changed the order and try to have some idea about which words you changed. Like this user. Then it would be easy to write a simple code to check the variations and find the correct seed phrase. Basically anything you can think of that can reduce the number of possibilities and come up with an algorithm.

I think it is clear enough. The thing is that variable length data is not a bitcoin specific thing. For example we have it in BER and DER encodings (note DER is used in signature encoding). the format is following the same pattern. We have an initial value (usually the first bit) that tells us how to read the follow up data. For example in DER if the first bit is 0 then your first byte is the value and if not then the first byte tells you the length of what you should read and what you read afterwards is the value:
DER: 0x32 = 00110010 (first bit is 0) so the value is 0x32 or 50
DER: 0x81dc = 10000001 11011100 (first bit is 1 so length is first byte or 1 byte and next byte is value) so the value is 0b11011100 or 220

The same thing is correct for Compact Int but instead of first bit we are using the first byte and a value comparison. The rule is that if the value of first byte (the first octet) is smaller than 0xfd or 253 then the first byte is the value itself. But if the first value was bigger then the follow up bytes are the actual value and first byte will indicate its length where 0xfd is followed by 2 byte, 0xfe is followed by 4, and 0xff is followed by 8.
0xff005f20054ebbe712:
first byte is 0xff so the first byte indicates the length to read and the length is 8 bytes so we take the following 8 bytes: 00-5f-20-05-4e-bb-e7-12 and the value is 5321341234651231

Here is a preview of an upcoming tool I am working on, you can see different encodings and their relative byte array and integer value:

This is an implementation bug (from 2011).
When signing a message using Elliptic Curve Digital Signature Algorithm (ECDSA) the first step (after finding e) is to choose a random number k∈[0,n] then multiply that with curve's generator point (G). The r value in the signature is the x coordinate of the resulting point.
Now when an implementation of ECDSA is using a bad RNG it can produce the same k and as a result produce the same r and consequently let an attacker calculate the private key that was used to create this signature.

P.S. This is one of the reasons why RFC6979 is being used by most wallets nowadays.

There is a way to do this with bitcoin but it requires combination of two technologies: Bitcoin's scripting language (specifically OP_Return) and Torrent network. This method does not need any servers or domains. The general idea is this:
1. You build your website, it can be a simple "Hello world" page to a complex e-commerce website with user registration,...
2. Make a torrent out of it and get its 20 byte hash (this is simply the hash that you insert in utorrent to download the torrent file)
3. Create a bitcoin address that will belong to your website. Send a transaction to this address and include the hash from previous step in its output with an OP_Return.
4. Now everyone who wants to visit your website has to look at that address, they simply check its last transaction and extract its OP_Return output to get the new hash. Then they download the website using that hash via torrent network by using something like webtorrent.

Ref: https://github.com/elendirx/web2web

The code is checking 24*2048=49,152 seeds and (based on my calculations) about 5% of them are valid which means 2,457 valid seeds! I may be missing something but 180 seems very strange to me.
BTW it is a very slow algorithm, not that it matters with this small number.

Something like this would be great:

I can come up with tests myself but then I wouldn't know if it is actually correct (does bitcoin-core RPC work for checking?).
Checked bitcoin-core tests[1] but couldn't find any test cases for non-regular scripts, all of them seem to be for normal (standard) scripts used in regular transactions.

[1] https://github.com/bitcoin/bitcoin/blob/63b9efa73d6bec280241fe0fa06abf7e5b4dde8d/src/test/script_tests.cpp
and txcreatescript... files here https://github.com/bitcoin/bitcoin/tree/master/test/util/data

To prevent TestNet addresses from being confused with MainNet addresses and prevent possible money losses.

No you won't. This topic is about the size of "blockchain" not size of signatures or transactions. Since block size will remain the same, the blockchain size will remain the same and grow at the same rate as long as new blocks are full.

I've been trying to finish it up and release it but other things keep coming up and I sidetrack.

In my experience these things don't depend on the chosen language but instead on the developer's experience. Any code written in any of the modern languages can be fast, secure and scalable if the programmer is good enough. And if not, it doesn't matter what programming language was used.
For example I always thought C# is a slow language because it is managed and has overhead,... but over the past few months I've been seeing how wrong I was to the point where I saw an article on how they implemented AES encryption function that was faster than the optimized C implementation!

If you want security then run security audits and you can even pay security experts to review your system.
If you want scalability then learn the programming principles that help with writing a scalable code.
If you want performance then learn more about performance improvements specific to the language you are using and also run benchmarks and profilers to find the bottlenecks and improve them.

If the size of the blockchain is the only concern in this discussion then instead of focusing on storing it elsewhere (which sounds more like centralization) focus on bitcoin transactions at byte level and see how you could "compress" them instead. FYI inside a transaction there are lots of wasted bytes that don't need to even exist. For your storage and even communication over P2P network you can come up with a compression technique that reduces the size by a lot.

I have actually been working on this recently and been able to "compress" a transaction up to 15%. That's just a start though, it needs a lot more work and study of other people's work to see what they have done, but you get the idea. With a block this can be more by simply dropping a lot of things and adding a "contract" in your compressor based on some factors such as block height. I expect the final result to be 30% compression.

Take a look at protocol versions and what they do here: https://bitcoin.org/en/developer-reference#protocol-versions