Do all Native Segwit addresses begin with bc1q?

[Pmalek]

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. 

[LoyceV]

1. What is the significance of the "q", and why that character?

I don't know. But I've always wondered why they use "bcq1" and not just "b" if it's always the same anyway. It would reduce the address size by 3 characters.

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". ~ 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.

That would be my guess too. I just checked: No Bitcoin address starting with "bc16" has ever been funded.

3. Are there Native Segwit addresses that don't begin with "bc1q" (like the one above), or is a mistake of some kind?

I can't tell if they still qualify as Native Segwit, but I do know some addresses start with something else. Example: bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd.

I just updated this overview yesterday:

(updated until blockchair_bitcoin_outputs_20211202)
~
Unique address count: 927,366,160
1... address count: 547,749,478
3... address count: 272,205,566
bc1q... address count: 89,702,297
...-... (with a "dash") weird address count: 17,707,628

Note that 927366160-547749478-272205566-89702297-17707628=1191. Those addresses are unaccounted for in the list.
These are the 1191 missing addresses (in chronological order):

bc1pqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqs3wf0qm
bc1zqyqsywvzqe
bc1pq2kqvpm76ewe20lcacq740p054at9sv7vxs0jn2u0r90af0k633322m7s8v
bc1pv22mcnt30gwvk8g72szz700n4tkkx2qur2adj6pt8hl37hcf9dascxyf42
bc1pxqsrzgpjyqejqdpqx5srvgphyquzqwgdd7yg9
bc1pxysyzgrpyp9zq63q2vs8xgp3ypdjqhguvkagn
........
bc1p8ysyjgrfypfzqu3q9usrqgpeyqnzqfgexpv74
bc1p23jk6urvv96x2gp3yqszqgpqyqszqgqa6qtuj
bc1pmfr3p9j00pfxjh0zmgp99y8zftmd3s5pmedqhyptwy6lm87hf5ss52r5n8
bc1pw2knldczhudzzydsns4lree0fafdfn4j4nw0e5xx82lhpfvuxmtqwl4cdu
bc1zw508d6qejxtdg4y5r3zarvaryvg6kdaj
bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx
bc1sw50qa3jx3s
bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd
bc1pz24mrc32d4rhze7x7qxeu7x3wn5c2ncuh7a7jrplvw2qt92xwvpqdr6zq2
........
bc1pju9e5c3n8xsp2p9ee60p3h6qy4fmsvsxhrazvq4mjpxtnpp2tvhscm58un
bc1ptld3dxjkxhpsng525rhj6wwcumsxtf7zp4d99jrurehdxsys6cdszx4xpe

[ABCbits]

1. What is the significance of the "q", and why that character?

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

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.

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).

[dkbit98]

I know that Taproot addresses are starting with bc1p, and Native Sewgit addresses start with bc1q.
Letter q is the bech32 encoding of the number 0 that should be witness version 0, but this can change in some future version updates.

Check out BIP 173 encoding table below:
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32

[Charles-Tim]

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

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?

[NotATether]

The "bc16" address mentioned in the OP is likely an address encoding error by Binance's software. [it was posted by ETF already, but] 6 is the 26th character in the bech32 encoding according to https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Specification (And q is the first).

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

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?

Yes.

[pooya87]

I don't know. But I've always wondered why they use "bcq1" and not just "b" if it's always the same anyway. It would reduce the address size by 3 characters.

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.

[Pmalek]

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).

Thanks for the source. If you scroll down towards the bottom, they list several Native Segwit address formats that are valid.

Besides addresses that begin with "bc1p" like LoyceV mentioned above, they can also start with a "bc1z".
One example of an address with an invalid checksum is one that begins with "BC13".

[LoyceV]

addresses that begin with "bc1p"

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

they can also start with a "bc1z".

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

One example of an address with an invalid checksum is one that begins with "BC13".

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

[Pmalek]

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

I don't think you ever will. They are a type of invalid address format for native segwit addresses. You probably couldn't generate such an address by any reputable wallet software. 

[pooya87]

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

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

[Pmalek]

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.

I have also found it interesting that on the link that was shared above, a really short address like "bc1sw50qa3jx3s" is a valid Native Segwit address. I have never seen anything that short. I remember that I generated bech32 addresses that were visibly shorter by several characters in the past, but nothing like that one.  

[pooya87]

I have also found it interesting that on the link that was shared above, a really short address like "bc1sw50qa3jx3s" is a valid Native Segwit address. I have never seen anything that short. I remember that I generated bech32 addresses that were visibly shorter by several characters in the past, but nothing like that one. 

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:

Code:

bc1sjq8qn0wcax
bc1s0fvtqh7c30rcmcvh49eq7pynnsrerfhcx5s53h3a0hp93lvdyr3vjgqmcwevnvxevgv0pc

[LoyceV]

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.

How is Blockchair.com broken if the transactions actually exist? See:
https://blockchair.com/bitcoin/transaction/c83bfc9946c88f78cf4708b991a3c1f54cbb1845ba5494fdd15478b202878f1e
https://blockchair.com/bitcoin/transaction/bb2a72503ce5be722cf45dbd9c784a4b44dbb9c54cf9ec71ad90c6cce5a60bc2
https://blockchair.com/bitcoin/transaction/9eebd7c7db9c73f057aa635a72c123327d91c0ad3956a9a91851419e647b1687
Or do you mean it shouldn't be shown as if it's an address? Kinda like what they do showing OP_RETURN outputs as "addresses"?

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

How? It would be really cool if you can transfer this dust and explain in details how you did it! I don't even know how it was created in the first place Both Bitcoin Core and Electrum don't accept these "addresses".

[achow101]

How is Blockchair.com broken if the transactions actually exist? See:
https://blockchair.com/bitcoin/transaction/c83bfc9946c88f78cf4708b991a3c1f54cbb1845ba5494fdd15478b202878f1e
https://blockchair.com/bitcoin/transaction/bb2a72503ce5be722cf45dbd9c784a4b44dbb9c54cf9ec71ad90c6cce5a60bc2
https://blockchair.com/bitcoin/transaction/9eebd7c7db9c73f057aa635a72c123327d91c0ad3956a9a91851419e647b1687
Or do you mean it shouldn't be shown as if it's an address? Kinda like what they do showing OP_RETURN outputs as "addresses"?

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).

How? It would be really cool if you can transfer this dust and explain in details how you did it!

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.

I don't even know how it was created in the first place Both Bitcoin Core and Electrum don't accept these "addresses".

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.

[Pmalek]

Take note it's invalid not because 4th character is "3" since "3" is valid representation of witness version.

Are you sure that's not the reason? The source explains that it's invalid because of an invalid witness version.

Here is the quote for the entire line where that address is shown:

BC13W508D6QEJXTDG4Y5R3ZARVARY0C5XW7KN40WF2: Invalid witness version

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32

[pooya87]

How is Blockchair.com broken if the transactions actually exist? See:

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).

How? It would be really cool if you can transfer this dust and explain in details how you did it!

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

Code:

    } else {
        if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM) {
            return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM);
        }
        // Other version/size/p2sh combinations return true for future softfork compatibility
        return true;
    }

You can also see the standard flag that rejects the transactions from mempool (but not from blocks) as non-standard.

[achow101]

Take note it's invalid not because 4th character is "3" since "3" is valid representation of witness version.

That is incorrect. "3" would to correspond witness v17, however BIP 141 states that the highest witness version is 16. This corresponds to OP_0 through OP_16 - there is no 17 or greater.

[gmaxwell]

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'.

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).

[franky1]

I know that Taproot addresses are starting with bc1p, and Native Sewgit addresses start with bc1q.

and here is the funny..
taproot was promoted that "no one will be able to distinguish if its a standard transaction or a taproot transaction.."
um.. the 'q' and 'p' kind of give it away