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

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.

1 Like

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?

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

1 Like

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:

Note that bitcoinChain is used for other coin types too, so probably some refactoring is needed first. Similarly for makeBitcoinEncoder and makeBitcoinDecoder.

Looks like right now the encoding just tries both (base58check, or bech32), so another try…catch could be made for the taproot scheme.

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?