The SHA256 implementation that bitcoin-core is using has a different set of functions for CH and MAJ operations done in this hash function. While they both are nice little optimizations for skipping 1 bitwise operation, I can't figure out the mathematical proof for them being the same.

For reference:

CH and MAJ are the functions from FIPS 180-3 while CH_alt and MAJ_alt are from bitcoin-core source code

If all you do is check if a set of words is a valid BIP-39 seed then it should not take more than half a minute* for 1 million keys not 7-8 minutes even without optimization. You are basically doing a SHA256 on a 264 bit input (entropy) so it is only 1 rounds of block mixing under the hood.
* The value is based on my test on 1 CPU core on a corei3 CPU with c# code of my own writing. With some SHA256 optimization, with parallelization (using all the cores) and some other optimization of the code the time can be reduced to less than 5 seconds for 1 million variations.

The problem is when you are adding the payment option in this design. First you have to decide whether this is a simple file sharing between peers (like Torrent) or is it a file selling between a content creator and his customers.
In either case I don't see any reason why you need a middle man (router) like LN since the file is only held and stored by the owner and nowhere else and he is already uploading it every time someone wants it.

If it is file sharing them it is just a matter of knowing the IP address of the one with the file and connecting to it. Basically P2P Torrent network instead of being a semi-P2P Torrent network (eliminating trackers).
If it is file selling it is the same as before but you only need a way to ensure payment, a multi signature scheme might work here.

You can use https://segwitaddress.org/bech32/ to test things on the web (it only accepts WIFs which you can convert from hex using bitaddress.org) or use any wallet that supports importing keys and Bech32 addresses.
This would be the resulting address:

No, but a search on GitHub returns one result: https://github.com/Bit-Wasp/bech32 (use at your own risk)

There is no such thing as "legacy private key". There has always been 1 type of private key, which is a number from 1 to curve's n-1.

https://bitcointalk.org/index.php?topic=4992632.0
Step 0 for you would be to get the public key from private key as you would any other time (private key * G).

That is the part missing from the bip...

There are 7 test vectors at the top of the list that are supposed to be "valid Bech32" but I can't see how they are valid.
These have no data since the bytes after the separator is the 6 byte checksum:
A12UEL5L
a12uel5l
an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharacter sbio1tt5tgs
?1ezyfcl


These have data but none of them are properly padded! They all have leftover non-zero bites (3 or 5)!
abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqc8247j
split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w


I can get the first group being valid since that is just encoding of empty data (which is not SegWit address and just encoding) but the second group doesn't make sense, shouldn't the data be properly padded in those too?

Thanks but I was hoping for a bit more than just what you could find on Google. For example most validation stuff seems to be happening in validation.cpp but I can't find anything related to my question and I always have a hard time reading c++ code so I don't even know if I'm in the right place or not!

(1) I can't figure out whether the data in OP_RETURN can be an arbitrary data with any format or or should it be formatted properly as a script. So when reading the transaction would it fail if it is not a proper script or ignored?
For example can the PubkeyScript be the following:
or should the "data" which is 0x20 here also be correctly formatted like this:
The difference between the two is that the first one, if read as a script, tells you push 0x20 byte data but has no data afterwards. The second one, if read as a script, tells you to push 0x01 byte and is followed by a single byte (0x20).

---

(2) If it is being interpreted as a proper script, can it contain any script code or are there limitations? (I do realize the script won't run since it is OP_RETURN!).
Is this example valid? (contains OP_DUP and OP_SHA1 after the PUSHDATA):

---

(3) Also is there anywhere I could see all the changes to OP_RETURN rules, any historical limits including but not limited to size?

All these numbers we are pushing on the stack are integers (Int32 or Int64 where there is an overflow chance). right?
There is no negative zero defined for integers! The negative zero in IEEE 754 is defined for floating point numbers (float and decimal)!
So what these lines are doing with [0, 0, 0, 0x80] is actually interpreting a completely different value (-2147483648) as so called negative zero by mistake.

What am I missing here?

It isn't that hard either. I just never knew how scripts worked when I started that project and never gotten around to upgrade it until now.
As for the size, there are certain small changed that can help create a smaller QR code. For example making the hex uppercase would make a big difference. Or you can do what Electrum does and use the Base-43 encoding on it before you turn it into QR.
Base-43 is exactly the same as Base-58 but with these character:

Funny thing is that I created my BitcoinTransactionTool project for the same reasons on top of other things. Basically you are looking for a way to make an unsigned transaction and give it to your cold storage for signing.
I haven't had time to work on it anymore ever since I made it and Electrum has changed a lot, but I'll probably fix its bugs and release the new version this month if I can get the script part of my library finished
Feel free to take a look at the code to get the idea (you can find it in my signature).

Well, I said "not exactly" so it is somewhat correct and when I said "false" I mostly meant the second part of what I quoted.
But basically when you are talking about elliptic curves in general, G is simply a point on the curve. In a specific curve like secp256k1 which bitcoin uses, there is only one G that is used as a standard for that curve.

As far as I understand the algorithm, there is only one possible P2SH-P2WPKH with current and only witness program version and that's what this code is giving you.

Thanks but now this no longer makes sense: https://bitcoincore.org/en/segwit_wallet_dev/#transaction-serialization
"Each witness field starts with a compactSize integer to indicate the number of stack items for the corresponding txin"

Additionally there is fd0102 value indicating the size of the public key script in the SegWit transaction which is in fact a CompactInt not an OP_PushData which should have been 4d0102 indicating length of 513 bytes (which is available in the legacy transaction as an OP_PushData). Note that these transactions were created by Electrum and are already in (TestNet) blocks.

I've added the files I mentioned above with a release which you don't have to use if you compile it yourself.
I've also added a bunch of comments in the main function to clarify what is happening. The rest of the code is also fully documented (since I copied them over from my main library project) so the functions purposes should be clear enough.

Here you go. https://github.com/Coding-Enthusiast/AddrConverter (going to add ReadMe, License and release in a minute)
And don't worry about "reward".

Well those applications all have the code to do all these stuff but they don't usually expose the functions through any kind of CLI because it is not used. You'll have to write something yourself. I can put together something for you in c# for the first part only (not the public key recovery) if you like.

Things you can not do:
- Get the 1xxx address from 3xxx address
Things you can do:
- Get the 3xxx address from the 1xxx address¹
- Get either 1xxx or 3xxx or basically anything else if you have published a signature with a message that you signed (this includes transactions that were spent from that key)!²

Here are the steps for (1)
1. Having the address starting with 1, perform a Base58check_decode on it to get the byte array remove the first byte as it is the version byte. The next 20 bytes are the hash160 (you can also open the address in blockchain.com explorer and it shows you the hash160 result!)
2. Write the "witness script" for the current version of SegWit which is
3. Perform HASH160 hash on the result of step 2
4. Append the P2SH version byte (=0x05) to the beginning of the result of step 3 and perform a Base58Check_encode on the result
=> now you have your P2SH-P2WPKH address that starts with 3.

Here are the steps for (2):
1. Decode your signature (base-64) and throw away the first byte. Then your first 32 bytes are your r value in little-endian order and the second one is s.
2. Append the default message to  your message (Bitcoin Signed Message:\n) with its length. Compute double SHA256 of it. This is the "message".
3. Recover your public key by knowing (r,s) and message. (I haven't released my library yet to add that as a reference but you should be able to find  this option in any library such as OpenSSL that has ECDSA capabilities)
4. Perform HASH160 on the compressed public key as bytes.
5. Feed it to step 2 of above.

This is the reference but in my opinion it is very vague: https://bitcoincore.org/en/segwit_wallet_dev/

Standards for Efficient Cryptography SEC 1: Elliptic Curve Cryptography
Section 4.1.6 Public Key Recovery Operation (Page 47)

I honestly don't know. I still have not been able to figure out how this particular type of address is derived from keys.