Topic: Do all Native Segwit addresses begin with bc1q? (Read 374 times)

There is nothing funny about that, and you came up with your own twisted conclusion about that.
Now you can't really distinguish if address is used for single or for multisig setup, and in due time more people will use Taproot address, just like most people today use bc1 segwit addresses.
It helps if you actually read how Taproot works directly even if you are not a tech expert, instead of reading random tweets and videos from some trolls.
My conclusion is that Taproot is not a magic stick that fixes everything, but it has some nice benefits and adoption is slowly growing if we look at the stats.

No one will be able to distinguish the spending conditions of the taproot transaction. Given that taproot will use entirely different signatures, different locking scripts, even different OP codes, it will obviously be trivial to identify taproot outputs. Indeed, there has been plenty of discussion about how early adopters of taproot will become part of a smaller subset of users and will therefore have reduced privacy in the short term.

None of this is new information and has been known and discussed for years.

Even more funny is that you've been criticizing things you don't even understand.
What taproot "hides" is branches in the script that aren't used in spending that output and only reveals what is necessary. That way not only it reduces the size but also increases functionality since the same output could for example be used in another layer or a side chain with those branches that weren't used on-chain.

The output itself is also indistinguishable since you can't tell whether one key owns it or multiple or whether a complex script is the key to spending that output.

Keep in mind that such outputs can be spent by anyone since there are no consensus rules for how they are spent. They will be considered non-standard if received in mempool and verification of them is skipped if they are found in a block.

1. Whoever said that explain Taproot poorly or fooled by media which overestimate Taproot capability.
2. It doesn't apply to P2SH-P2TR or P2WSH-P2TR.
3. The 'q' in 'bc1q' doesn't refer to Taproot.

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

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

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.

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.

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:
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32

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.

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"?

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

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:

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.  

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

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. 

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.

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

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.

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


Yes.

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?

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

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

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.

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

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.