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:
- mandatory prefixes
- mandatory length if interpreted version bytes is 0 (0 by default)
And the addition of the following features:
- HRP (Human readable part) field in the encoding window
- Nullification of "Network" and "Script ver." if HRP isn't
bc or tb
Rationale:
- 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.
- 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.
- 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.
- 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).
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:
And the addition of the following features:
bcortbRationale:
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
tbin the hrp, in testnet bitcoin lightning you'd see the network + the amount requested in the hrp - for example:tb20mrepresenting 20 mbtc.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.
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.
bcortbAnother implementation nit. If the network isn't bitcoin layer 1, these fields should be greyed out (nullified).