Not support bc1q(Native Segwit) or bc1p(Taproot) BTC address

🪳 Bug Reports
1

Currently, lots of BTC users use bc1q or bc1p BTC address for BRC-20 or Ordinals NFTs. ENS should supports bc1q and bc1p BTC address.

image
image1086×842 62.9 KB

1 Like
2

Currently for BTC, the encoder library uses base58check (P2PKH and P2SH), or bech32 (segwit).

Those addresses appear to be something new, right? What encoding scheme(s) do they use?

3

A JavaScript Lib: Taproot address validation · Issue #1919 · bitcoinjs/bitcoinjs-lib · GitHub

1 Like
4

Cool! Looks like that is just for validation, not for encoding/decoding, and it’s still in progress anyway. But if you know what needs to be done for encoding/decoding, here is where the pull request should be made: https://github.com/ensdomains/address-encoder/blob/master/src/index.ts#L1467

Note that bitcoinChain is used for other coin types too, so probably some refactoring is needed first. Similarly for makeBitcoinEncoder and makeBitcoinDecoder. https://github.com/ensdomains/address-encoder/blob/master/src/index.ts#L168

Looks like right now the encoding just tries both (base58check, or bech32), so another try…catch could be made for the taproot scheme. https://github.com/ensdomains/address-encoder/blob/master/src/index.ts#L144

5

The address bc1pxe5uh7cst3p3qzsuzng0r94uv0tn4wfzum2jflph0km6sjjjp5cqc4906u decodes as:

{
  type: 734539939, // bech32m
  hrp: 'bc',
  version: 1,
  data: Uint8Array(32) [
     54, 105, 203, 251,  16,  92,  67,  16,
     10,  28,  20, 208, 241, 150, 188,  99,
    215,  58, 185,  34, 230, 213,  36, 252,
     55, 125, 183, 168,  74,  82,  13,  48
  ]
}

It’s a bech32m encoding with a version of 1 which should get stored as <byte:version:1><byte:length:32><bytes[]> in ENS.

I think we just need if version = 0, use bech32, otherwise use bech32m?

Also I think there is an upcoming rewrite of this library?