Topic: weird bitcoin addresses and bech32 address format prefix (Read 351 times)

I did forget to reply on this thread, this is solved long time ago. However thank you all.

Hope you don't mind my replying - it's very easy actually:


Don't calculate the checksum manually because all base58check algorithms on Python I checked (pun not intended) all apply it at the end for you, so it will actually make a wrong address if you do that.

That is correct but it is also not any kind of meaningful advantage or disadvantage to be able to tell what locking mechanism is used to lock up those coins.

Right.
Both nested segwit and legacy multi-signature addresses start with 3 and you can't know whether the address is segwit or not if the owner of the address has never make any transaction from that.
An address starting with bc1q is a single-signature address, if it includes 42 characters and is a multi-signature address if it includes 62 characters.

Yea, my point here is the 3 address has a fixed length, you don't even tell it is multisig, single sig or some other scripts at all. But with bech32, you can easily tell apart a single sig from a multi sig. Right?

Wrong, bc1p only refer to Taproot address. Multi-sig is just one of many things you could do with Taproot script. And FWIW, bc1p actually use Bech32m[1].


Don't forget SH in P2SH and P2WSH refer to Script Hash, so it's possible the spend condition isn't N-of-M signature.

[1] https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

So, i think the P2SH "3" addresses at least win this round: until it spends, you don't tell at all whether it is a single sig or multi sig.
I think I am right on this point. What do you think?

Thanks again. Makes sense now, ok.

Does anybody know if we can use pythons' bit (by ofek) to compute the hash160 of an arbitrary address ? I'd like to see a python example which is very fast and can handle nicely all possible address types.

In short P2WSH is encoding a 256-bit hash that is the result of SHA256.

P2WPKH and P2WSH are different.
To create P2WPKH we compute HASH160 of public key (so we have a small 160-bit digest) which is then encoded using Bech32 to get that short address you see.
To create P2WSH we have a "redeem script" which we compute its SHA256 hash (so we have a 256-bit digest) which is then encoded using Bech32 to get that longer address you see.

Yes this is the correct SHA256 digest for that address.

The ice library thing you used doesn't seem to support decoding P2WSH addresses for some reason.
https://github.com/iceland2k14/secp256k1/blob/691e238c4a05c4bc93959fa339df341f24113919/secp256k1.py#L400

The address_to_h160 you called using the P2WSH address should have thrown an exception instead of returning a value since it is meant to decode P2PKH (Base58 encoded) addresses and not anything else.

@pooya87 or @all:

could you please explain to me why I can't determine the hash160 of a long P2WSH bc1 address ? Here is an example of a short (P2WPKH) bc1 address and a long (P2WSH) one


pycoin library outputs the hash160 correctly (27ff647db2c3b79031b12ad747409b696c8a1690) but only for the short P2WPKH address, no output for the P2WSH. Why?

So I tried iceland2k14/secp256k1
which returns

which doesn't seem to be valid. Icelands' secp256k1 generates an incorrect hash160 for the short bc1qyllkgldjcwmeqvd39tt5wsymd9kg595su2tnp8 address. Seems like secp256k1 is not bech32 capable so better not to use it for such things.
I was able to successfully determine the correct hash160 of the short P2WSH address just by using bech32 python library and a small python program, but I am not sure if the result is correct. Is this the correct hash160 for the P2WSH address mentioned in the example ?

I was trying to use python's bit library, I see there is a function defined for hash160 generation, it's located in bit.crypto

but I was not able to utilize it correctly.

No. For forward compatibility the consensus rules have to assume any transaction spending any of the future witness versions (currently anything >=2) are valid by only performing minimal checks. Otherwise any future witness program has to be activated through a hard fork instead of a soft fork.

If the output script is OP_NUM + a single data push with total size between 4 and 42 it is considered a witness program and the interpreter will only check the following 2 if the OP_NUM is anything except OP_0 and OP_1:
1. Signature script of that input is empty
2. Program doesn't evaluate to OP_FALSE

bc1sw50qgdz25j is OP_16 <751e> and since 0x751e is not equal OP_FALSE anybody can spend any coins sent to this non-standard address without needing to provide any signature or anything since witness version 16 is not yet defined (we only have version 0 and 1).
Although because of it being non-standard, almost all full nodes reject such transactions and user has to contact a miner to include them in a block.

did you mistype and meant rather "no one can spend the coins" ?

Thanks a bunch pooya87

Bech32 encoding has 3 parts:
(a) a human readable part that is "bc" for bitcoin (other chars used for other coins/chains)
(b) a separator which is always "1"
(c) the data part that is at least 6 characters long. In bitcoin (SegWit) addresses the first character is the witness version.

Bitcoin's Bech32 addresses are only defined for 2 witness versions and a total of 3 address types:
* P2WPKH that is using witness version 0 and is a short address encoding 20 bytes of data (pubkey hash) and starts with bc1q (q being the witness version)
* P2WSH that is also using witness version 0 and is a longer address encoding 32 bytes of data (script hash) and starts with bc1q (q being the witness version)
* P2TR that is using witness version 1 and is as long as P2WSH address encoding 32 bytes of data (tweaked pubkey) and starts with bc1p (p being the first byte of the data encoding the witness version).

The reason why you find so many addresses starting with bc1p is because Taproot was activated a while ago and people are using it hence the addresses.

Any other address you see that is using a different length or a different witness version (bc1sw50qgdz25j with s being witness version 16) is non-standard and anybody can spend the coins sent to these addresses because there are no consensus rules defined for them yet.

1 is only used as the separator not as part of the bech32 charset for encoding which is why you will never see it as part of the encoded data.
Note: If you see a string like this the human readable part is actually "bc1p" and the second 1 is considered as the separator and everything after that 1 is the data.

A separator was needed, symbols would have made copying harder so "1" was chosen. When it is used as separator it should be removed from the charset. More here.

There is some discussion related to those addresses here, in this project of LoyceV.

https://bitcointalk.org/index.php?topic=5254914.0;all



They are very few, and problably those funds are lost. Probably wrong generated addresseS?

Adding to the above, bc1p is multisig iirc.


Was there any other question? I read the link and found "1" is excluded from the address because it's excluded from base58 - that was done for readability I think as "o" was also removed.

Also blockchain explorers not picking up new addresses is because their developers are lazy. 5 years down the line and they've still not worked out how to do it...

Thanks for the link, I already have this tab opened in my browser and red it. Unfortunately I wasn't able to answer my questions hence I did put them onto this thread.

Actually bech32 addresses start with bc1 and the next character comes from the witness version.
More of your questions may also get answered after you read this: https://en.bitcoin.it/wiki/BIP_0173

Hello everybody,

stumbled over a few weird addresses and looking for an explanation. As you see in the block explorer, the addresses had incoming transactions and UTXOs because the coins were never spent.


Question 1)
how does it come such short and valid bech32 addresses exist ?

---

until now I thought that all bech32 addresses always start with the prefix 'bc1q'. The mentioned examples above don't fit into this scheme as we see. On many info pages 'bc1' is mentioned as prefix. Out of curiosity, I looked at all the funded addresses on the blockchain to see what exist. There are thousands of addresses with prefix 'bc1p' and I immediately recognize that they have more characters than the usual ones with bc1q.

Here some examples:


Question 2)
I guess the longer addresses are P2WSH and the short ones are P2WPKH ?

---

Question 3)
how can it be that so many 'bc1p' addresses exist but this prefix is not mentioned at all in any known blockchain info site?

---

what's also interesting to see is the fact that there are many bc1p0 and bc1p2 and bc1p3 ...etc. addresses but no bc1p1 prefixed addresses.

Question 4)
Why? Although the chart '1' is allowed in the base58 charset. What cirumstance led to this fact that no such bc1p1 prefixed addresses were generated and seen out there ?