We often hear how Native Segwit addresses begin with "bc1", but the 4th character in a Bech32 is also interesting. It is always a "q". At least I though that it was always a "q". If you look up transactions in recent blocks, for example, you will notice that the "q" seems to always be the 4th character (unless it's a Taproot address).

I have three questions:

1. What is the significance of the "q", and why that character?
2. If the "q" is the standard or a must, how do you explain this Binance support article that talks about Segwit addresses? In the screenshot, you can see that the address on Binance begins with "bc16". The info in the article may not be completely correct, but the screenshot is surely not a mistake.
3. Are there Native Segwit addresses that don't begin with "bc1q" (like the one above), or is a mistake of some kind?


I tried scanning the above address with Electrum on my mobile and the app is importing an Ethereum address. It might be possible that they did that on purpose for whatever reason. Maybe to prevent people from sending coins to it and then blaming Binance for their mistakes. 

The 4th character refer to witness version, where "q" is witness version 0.


Must be typo, "6" refer to witness version 26. See table on section Bech32 (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32).

Bech32 prefix for mainnet is bc while 1 is the separator, q is the witness version 0 for native segwit. I learnt all these from some pooya87's previous posts which is also in accordance with yours. But p is the witness version 1 for P2TR?

It has to do with the damn copycoins.
Bech32 creators should comment on this but it looks to me that it was designed in a way that when the copycoins copy bitcoin they can, with minimal effort(!) change the "human readable" part and get their own address and avoid confusing the users like how Base58 encoding does.

The initial choice was probably between using the full abbreviation 'btc' but they went with the shorter version 'bc'.

As you can see from SLIP-173 there are already lots of HRPs for different copycoins taken.

I've seen several of those that actually spent the funds again, so they must be valid addresses.

I've seen only 2 (bc1zqyqsywvzqe and bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj), and no funds have been spent from them.

I haven't seen any of those in the wild.

As far as address strings are concerned these 2 strings are technically invalid because they are using BIP173 instead of BIP350. In other words blockchair.com is broken.
It may be interesting to know that anyone can spend the funds in such addresses since we don't have witness version >1 activated yet. About $0.7 reward awaits

The consensus rules dictate that a witness program has to be between 2 and 40 bytes so the smallest bech32 address string you are going to get is 14 characters long and the biggest 74.

If you are wondering about the difference, that's because bytes are 8-bit each but a bech32 string characters are 5-bit each. The length also includes the HRP and separator characters. There is also a 6 character checksum at the end.

Here are examples with random bytes:

No. Segwit v1+ outputs use bech32m (defined in BIP 350), so the correct address to use will be slightly different at the end (the checksum is computed slightly differently in bech32m).

Because segwit v2+ are not yet defined, these outputs are anyonecanspend outputs. They can be spent in the same way that b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41 spends segwit v1 inputs prior to taproot's activation.

They only don't accept them because addresses that encode segwit v1+ scripts must use bech32m. Otherwise these addresses would be accepted as BIP 173 states "implementations MUST allow the use of any version" so that older wallets can still send to new segwit versions when they are deployed.

At blockchain level we don't have addresses, we have scripts. Block explorers (wallets, etc.) take those scripts and convert them to their corresponding address. In case of SegWit output scripts they have to take the witness program and witness version and encode them using Bech32 encoding. But when witness version is 0 they should use Bech32 (BIP-173) and when version is 1 and more they should use Bech32m (BIP-350).

Blockchair is taking the program and version and encodes them using Bech32 which is wrong and should be rejected if given to any wallet software for payment (there is a flaw in BIP173 encoding that affects programs with unfixed lengths).

I won't be able to do it because such transactions are considered non-standard by majority of bitcoin nodes so they will never reach a miner.
@achow101 posted a good example which is spending Taproot outputs before it activates without providing any signature or witness. This is most probably created and mined by a miner (another indication is the 0 fee).

The way it works is due to forward compatibility. The current clients have to be able to ignore verification of future versions so that any future witness version doesn't need a hard fork. So the existing nodes simply skip verification of witness versions above what they understand (which is currently 1).

This little "else" expression simply returns true for any witness program currently bigger than 1 or version 1 programs that are not 32 bytes or if you wrap it in a P2SH script.
https://github.com/bitcoin/bitcoin/blob/65b49f60a4cf521889297b2006f66efa11d769c5/src/script/interpreter.cpp#L1959-L1965
You can also see the standard flag that rejects the transactions from mempool (but not from blocks) as non-standard.

Yes, though we didn't fully appreciate the depravity of clones and the creation of so clones that fraudulently call themselves "bitcoin"-- though fortunately as far as I know none of the name clones have kept the HRP.

And indeed, it was designed to be both easy to change and also less excusable to not change "What do you mean FooCoin address, it begins with BC ... Bitcoin!". 

BC was shorter than BTC... I personally also liked the homage to the original Bitcoin icon (which was a coin with BC in it).