Blockstream still using Bech32

[Flavatron]

Hi everyone,

I've been experimenting with deriving a Taproot Bech32m address using Bitcoin Core 0.22.1 and noticed something interesting. It seems that Blockstream's explorer on testnet3 is still displaying addresses in the Bech32 format.

I sent a transaction earlier today to fund the wallet for testing the preimage condition.

Bech32m Transaction:


However, when I checked the transaction on Blockstream's explorer, the address was shown in the Bech32 format.

Blockstream Explorer (Bech32):


I understand that updating explorers might not be the top priority, and I'm not raising this as a complaint. I used to run my own block explorer in the past, but lately, I've been using online services for convenience.

I'm curious about how the Taproot rollout has been going overall. I'm genuinely impressed with the careful thought, planning, and execution behind it. Taproot seems like one of the most significant changes I've witnessed in Bitcoin, and I'm just starting to explore the exciting possibilities it brings with its added functionality and privacy features.

Would love to hear your thoughts and experiences with the Taproot upgrade.

[1714235501]

1714235501

[1714235501]

1714235501

[1714235501]

1714235501

[1714235501]

1714235501

[1714235501]

1714235501

[nc50lc]

However, when I checked the transaction on Blockstream's explorer, the address was shown in the Bech32 format.

Blockstream Explorer (Bech32):

Image shows that the address is in bech32m format (starts with "tb1p") and is "V1_P2TR" (Pay-to-TapRoot) type.
On the other hand, bech32 format for testnet should start with "tb1q" instead.

The other image seems to be corrupted so I can't see the matter of concern.
-edit-
now it's working, the address has the same format but not the same address as the other screenshot.
It appears that it has the wrong checksum for some reason.

[pooya87]

Image shows that the address is in bech32m format (starts with "tb1p") and is "V1_P2TR" (Pay-to-TapRoot) type.
On the other hand, bech32 format for testnet should start with "tb1q" instead.

The explorer says P2TR based on the script (OP_1 <data>) not based on the address.
Also the address starting with tb1p means it is version 1 witness, you can not tell whether it correctly used the new encoding (Bech32m) for its encoding or not.
The only way to know that is to use a decoder to decode the address string and by verifying its checksum, figure out which version of Bech32 encoding was used.

OP didn't post the address string for me to check it myself and it is very hard to type it using the picture...

[nc50lc]

OP didn't post the address string for me to check it myself and it is very hard to type it using the picture...

Here are the strings:

• from "Bech32m Transaction" image: tb1ph68pa6mfyjqwlphet776empcppx6pe9ga5n45f4zwd0x4rnaj5zqn0g9wx
• from "Blockstream":                        tb1ph68pa6mfyjqwlphet776empcppx6pe9ga5n45f4zwd0x4rnaj5zqxncfty

BTW, my reply is based from what's shown in his image.

[pooya87]

OP didn't post the address string for me to check it myself and it is very hard to type it using the picture...

Here are the strings:

• from "Bech32m Transaction" image: tb1ph68pa6mfyjqwlphet776empcppx6pe9ga5n45f4zwd0x4rnaj5zqn0g9wx
• from "Blockstream":                        tb1ph68pa6mfyjqwlphet776empcppx6pe9ga5n45f4zwd0x4rnaj5zqxncfty

BTW, my reply is based from what's shown in his image.

That's odd.
The first address ending in wx is encoded using Bech32 (BIP-173) so it is wrong.
The second address ending in ty is encoded using Bech32m (BIP-350) so it is correct.

To OP: what tool returned that JSON in first image (containing the first address) because that's where the problem exists not with Blockstream explorer.

[Flavatron]

Hello everyone,

Sorry for the delay. I was away for a few days.

Thank you for your  observations and clarifications. You're correct of course, and I appreciate the insight provided here. It seems I had mixed up the encoding formats. Your detailed responses have helped clarify the matter.

Finding a suitable Bech32m library indeed presented a challenge, prompting me to improvise a bit by hardcoding the Bech32m constants into the existing Bech32 encoding scheme. It's a workaround, but it served the purpose for the task at hand.

I've added a collection of tools to a GitHub repository which allows users to generate a Taproot address, tweak public keys, and set spending conditions.

For anyone interested( I hope useful to some folks)

https://github.com/test-sum/taproot-tools