slowli / bech32-buffer Goto Github PK

Can you add new demo pages for the new Bech32m format which gets introduced with the Taproot upgrade? (BIP 0350)

Allow to encode and decode Bitcoin addresses from Base58Check to Bech32 and back on the demo page.

If you encode something with prefix LNURL, it's not possible to decode.

The bech32 npm package converts the prefix to lowercase (lnurl) before encoding it. I think that's the way to go.

Check that the prefix is not mixed-case (?) and convert to lower case before encoding. Otherwise, the encoded string may be deemed invalid by decode.

It always says "Error: Excessive padding: 5 (max 4 allowed)" I think this shouldn't happen.

Automate the testing of the demo page with the Selenium WebDriver.

Hello sir!
I was wondering if it would be possible if I could use this tool in Google Sheet?

I am having to convert hex identifiers to their bech32 prefix to match validators properly within our chain.

Would it be possible to make it so I could use it in a format like:(example)

https://slowli.github.io/bech32-buffer/data/?tag=vdlvalcons&encoding=bech32&data=4C1438CDA672B766D7BA69A79DC462DD389875BE

and then be returned:

vdlvalcons1fs2r3ndxw2mkd4a6dxnem3rzm5ufsad7058gmw

I initially made this PR -> #10 because I originally thought the solve would be a simple length check fix, however it seems there are a few more considerations required to ensure lightning network invoice compatibility.

The most important to mention is the removable of the following constraints:

1. mandatory prefixes
2. mandatory length if interpreted version bytes is 0 (0 by default)

And the addition of the following features:

3. HRP (Human readable part) field in the encoding window
4. Nullification of "Network" and "Script ver." if HRP isn't bc or tb

Rationale:

1. mandatory prefixes

Enforcing mandatory prefixes effectively enforces an only bitcoin address input, since lightning invoices do not have static hrp. For example, whereas for a testnet bitcoin segwit address you would see tb in the hrp, in testnet bitcoin lightning you'd see the network + the amount requested in the hrp - for example: tb20m representing 20 mbtc.

2. mandatory length if interpreted version bytes is 0 (0 by default)

This is more an implementation nit, if 0 is default then non bitcoin addresses are applied to this enforcement. This should be optional, not default.

3. HRP (Human readable part) field in the encoding window

The hrp represents important information that can't always be expected to fall into a prefix. Even though lightning has a standard, predictable template I think for a bech32 encode/decoder this should be more free in case other usecases for bech32 arise.

4. Nullification of "Network" and "Script ver." if HRP isn't bc or tb

Another implementation nit. If the network isn't bitcoin layer 1, these fields should be greyed out (nullified).

Yes, BIP-0173 specifies a max 90 char limit for addresses, however bech32 encoding is used outside of bitcoin, specifically in Lightning Network's Bolt11 where the majority of payment requests are encoded in bech32, and whose size is significantly larger than 90 chars most of the time.

Enforcing the limit makes this tool unusable for anything Lightning Network related, I request that the limitation is removed. I can supply the simply PR removing the relevant code