I have actually never had the chance to learn how nested-SegWit addresses work. But since they are derived from one public key and by publishing your signature + your address (1xxx) you are revealing your public key, it should not be hard to get the 3xxx address from it.
The public key of the address you linked is:

This part is false.
G is not exactly a "constant" and is not derived from the curve. G is one of the point on the curve that we have chosen as the "generator" of the curve. And that means multiplying any value from 1 to order of G yields another point (not a string of characters!!) on the curve which would be your public key. And that is the basic of asymmetric cryptography.

This is false. Legacy transactions don't have higher size, they have higher weight.

FTFY

This if false. The number of characters can be different and it is between 25-34.
58 is the total number of characters in the base we are encoding this to. eg. Base-16 has 16 characters.

---

In any case to answer OP's question the problem is that when you are proving ownership of an address, what you really are doing is that you are creating a signature similar to when you sign a transaction. And when others verify that, what they really do is that they recover your public key from that signature then verify whether it is valid or not.
Where does address come in? Basically nowhere. We also include the address because when they recover your public key from your signature they might end up with multiple possible public keys, including the address helps narrow the possibilities down to only 1.
What about SegWit addresses come in? The problem is that there still is no standard for them. I saw one of these hardware wallets (Trezor?) had a personal defined standard where they added 1 byte to the first byte of the signatures. But apart from that, you won't find anything globally accepted.

Since this IS possible your only option is to ask the wallet developers to add such functionality for you or come to some sort of agreement with the other party you are trying to do a "proof of funds" with to come up with some sort of standard like sending a transaction out of the address with a message attached would work but it will cost you fees.

Here are two transactions I've made as a reference (TestNet):
P2SH: 7c1819fe9b52a199c9a422b1df3edef43005c3d4eea367d7830bbc060a6aac44
P2WSH: 3e7aaf12e77e5d68b2bc26fb5cfe3ee3108356860056da923a2e735ba4759d58

The first one obviously has a scriptSig and the second one has an empty scriptSig + witness. The following two parts are the corresponding data respectively.
CompactInt refers to this so 1000 would be fde803
OP_PushData refers to values that are interpreted as an OP code and indicate raw data to be pushed on top of the stack. so 1000 would be 4de803
DerInt refers to length in DER TLV encoding and 1000 would be 8203e8

fd4606
CompactInt showing length = 1606
00
OP_0
48
??
30
DER sequence tag(0x30)
45
DerInt length = 69
02 21 00{..32 byte r..} 02 20 {..32 byte s..} 01
rest of the DER encoding...
{..14 similar signatures removed..}

4d0102
OP_PushData = PushData2 | 513 byte
5f
OP_15
21
PushData = 33 byte
02 083f75b6cf2aea023d86a6f757345508a2f7a1de23c1d015b6bc228e995cf2b7
Pubkey
{..14 similar pubkeys removed..}
5f
OP_15
ae
OP_CheckMultiSig

---

11 (count = 17)
CompactInt showing count= 17
00
OP_0
48
??
30 45 02 21 ....
Same signatures and variable types as above

fd0102
CompactInt showing length = 513
5f 21 02 4c231e0db.... 5f ae
Same script and variable types as above


I think I have gotten everything right, but I can not figure out what the two 0x48 values are. Although it doesn't make a difference because of the size of the value, for the sake of "correctness" I would love to know whether they are both CompactInt or if the one in witness is CompactInt and the one in ScriptSig is an OP_PushData (with value = 72)

Keys are chosen based on the order of the generator of the specified elliptic curve. Bitcoin uses a curve that has a G with an order that is slightly smaller than 2²⁵⁶ so the space is technically smaller than 2²⁵⁶.

Bech32 (like Base58) is just a method of encoding the same exact data that is the result of RIPEMD160 so it is limited by the same size (20 bytes hence the 2¹⁶⁰). In other words in legacy addresses and native SegWit (Bech32) addresses you are encoding the same thing. You can take a look at this topic that I posted a while ago if you are interested to know how it works with an example. The steps 1, 2 and 3 are the same with Base58, Bech32 or any other future encoding we might use.

When a miner finds a new block they have to "make" a new transaction and "pay" themselves the reward. The amount of that reward can be from 0 up to the maximum allowed by the block reward based on its height + the total amount of fees of the transactions included in that block. In other words it can also be 0 which is what happened here.

In this case, this block is found by a miner who has been doing "merge mining". What that means is that while the miner works to find a bitcoin block, they can find hashes that satisfy the other altcoin's difficulty and be a valid hash for their block, so they find a block of that altcoin too. In this case the miner was merge mining RSK (rootstock), and to do that you have to add that extra hash you found as a new output in that special transaction (the coinbase tx) with this format: RSKBLOCK:<32 byte hash>. This miner, instead of adding that as a new output, added it as the only output and with a bad format too so he lost the reward (>$48k at current price) of that block he just found.

I know two which are pretty much equal but sometimes have little differences:
- The developer's documentation: https://bitcoin.org/en/developer-reference (you can edit this on GitHub if you find something wrong or missing)
- Bitcoin wiki: https://en.bitcoin.it/wiki/Protocol_documentation

Bitcoin has one of the best documentations but unfortunately it is not updated regularly with new changes. I've been updating it as I go through things but haven't reached that part yet.

To answer your question you have to look at bitcoin-core's code: https://github.com/bitcoin/bitcoin/blob/3f125151998d9fead198fd44243dd64006b5a56b/src/protocol.h#L380
Which is addition of MSG_TX (=1) and MSG_WITNESS_FLAG (=1 << 30) which is basically giving you this:
0b01000000_00000000_00000000_00000001

Maybe the term "illegal" was an ambiguous term, my English was not helping me find a better word!
By "illegal" I mea whether the transaction containing an empty script would be invalid in a block. As you can see from the transaction I posted in OP it was perfectly possible in 2015 to have such transactions, I want to know if anything has changed.

BTW nonstandard means bitcoin-core nodes automatically reject these transactions and won't relay them. They are not breaking any rules though which is why they can exist in blocks.

If illegal, since when?

(If any readers are curious, here is an example: 8ec3e3dd39150798d71c61ffb7cc18ade6f2a2958378e18b7a98eefb709e7322 spent by f21b099d67070a7639d384f30e9b139bab58c27e47368a2d8152f05c14e187b7 which is the smallest tx record)

Maybe it is time to add page numbers to trust pages! It may even reduce the pressure on database too while loading some of these user profiles.

It is impossible to create a "bitcoin address" without a computer because it will probably take till the end of time for you to perform the necessary mathematics and functions that are involved in the process.

What you may be referring to is creating a "private key" without a computer while using another source of randomness. That can work. Coin flip is an option, since a private key is a 256 bit (binary or zeros and ones) you have to flip the coin 256 times and each time make a note of which side it lands on then you have your private key. Note that you may have to do a check to make sure you didn't produce a number bigger than N (order) even though the chances are minuscule.

But to get the "address" you will need to first do:

• the Elliptic Curve multiplication which is the hardest thing (keep in mind this is not regular arithmetic like 10 + 10 = 20, this is modular arithmetic like 10 + 10 ≡ 9 (mod 11) with 256 bit numbers)
• then take the result and perform the SHA256 hash on it (which is less hard compared to previous step but still very hard and time consuming)
• then perform a RIPEMD160 hash on the result (again nearly as hard as SHA256)
• and finally do a baseX (58 or 32) encoding which might be the easiest step but still time consuming.

In all the above steps, it is not just about the amount of time it is going to take or the hardness of each step but mostly about the very high possibility of making a mistake. If you do a single operation wrong then your final result is going to be false and any coins that you send to that resulting address is lost for good.

Here is something you can read: https://www.swansontec.com/bitcoin-dice.html

If you are fast and a little lucky you can stop this. But it will only work as long as the other transaction (51ff1786...) is not confirmed.
1. Go to https://electrum.org/download.html and download the latest wallet version, verify its signature and install it.
2. Import your seed and let it sync (you may not need to do this, you just have to open the newly installed wallet.)
3. [Important]From menu select File > New/restore option and follow the steps to create a new wallet. You have to create a new wallet to get a new address because your other wallet with all its addresses (even the ones you generate in the future) are compromised.
4. Select a new address from the new wallet and go back to other (old/hacked) wallet and send all your coins to this new address. [Important]Set the fee to 45 satoshi/byte. This amount is according to mempool about 15 satoshi/byte higher than the minimum for high priority transactions and you want to get your new tx confirmed as fast as possible.

P.S. I doubt that the hacker is watching the mempool for double spends but if they are then you have to repeat step 4 with a higher fee in an arms race to get your transaction confirmed faster than the hacker.
And good luck.

Altcoin Development and Technical Discussions in general. Basically this board but only focused on anything that isn't or can not be implemented in bitcoin. In fact for some time now, I have been wishing we had such a board as a subcategory of the board I linked.

You misunderstood my question, I am not asking about disadvantages of using these libraries. I am asking the developers what are the things that you might have noticed are missing from such libraries. Since I am currently developing one I would like to address some of these missing features as best as I can. I have some ideas myself which I shared here and am looking for more.

Does lack of reply mean lack of interest in what I started here or does it show there no longer is any developers on bitcointalk?!

I believe you are correct, and that was my mistake. The problem is that these methods are not that popular and are nothing like the established cryptography functions that are currently in use, so finding information about it is hard. The best thing I could find was an academic paper called "Generalized Scheme For Fractal Based Digital Signature (GFDS)" which proposes a digital signature scheme based on Mandelbrot and Julia fractal sets hence my reply above.

@odolvlobo
That is not what I was looking for, I am not planning on modifying the BIP itself or submit a new one. Just the "implementations".
For example these are reference implementations for bech32 encoding, it lacks c#, or this has only one c# implementation and is pretty bad (IMO) because of its unnecessary complications.
So my question is if I wanted to submit my BIP39 implementation which I already have or maybe if I wanted to add the bech32 that doesn't exist, what are the things that I should consider? For example of the top of my head should it only be implementation of that particular BIP or can it be part of the bigger library having other stuff?

I believe this is what you are looking for: https://gobittest.appspot.com/ProofOfBurn
Example address: 1StackBitcoinEaterxxxxxxxxy15E1Hp

Generally speaking what kind of conditions should an implementation meet to be added to a BIP as a reference implementation?

Specifically speaking In case of BIPs that already have implementations in certain language listed but the implementation is not so good. (I usually try to contact the developer and get the already existing code fixed but sometimes it is easier to make a new one rather than changing the old code.)

This number still seems to be way bigger than actual possible number of seeds. Are you sure you are only checking the valid ones?
There is a 4 byte checksum in them and although the collision chance of 4 byte out of SHA256 hash is higher but I don't think it is high enough to produce that many variations. (I'll try to test it in the afternoon when I get back home).

Edit: I ended up testing it anyways. With 12 words it seems that about 5% of the combinations are correct. The rest should be rejected. So with your words there should only be around 40 million seeds to check not that huge number you posted.
Also:
Two questions, is it the number of seeds you check per second or is it number of keys that you derive from those seeds per second? If it is the first one then it is very slow, I am getting 16k/s with my c# managed code using only 1 CPU core (corei3)! You should be able to get around 100k at least if you run it on parallel and with a stronger CPU.