[Lightning-dev] Invoice Address Format

[Varunram Ganesh]

Hello List,

The reason why we use bech32 for invoice addresses and raw hex encoded pubkeys and has long puzzled me. Let's take a sample testnet invoice

>>> "lntb20m1pvjluezhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfpp3x9et2e20v6pu37c5d9vax37wxq72un98kmzzhznpurw9sgl2v0nklu2g4d0keph5t7tj9tcqd8rexnd07ux4uv2cjvcqwaxgj7v4uwn5wmypjd5n69z2xm3xgksg28nwht7f6zspwp3f9t"
<<<

of length 271 from the BOLT 11 RFC for consideration. While the bech32 format has its advantages being base 32, easy to read out over phone and stuff like that, I wonder if it is optimised for this specific use case since BIP-173 states


>>>
The specific code chosen here is the result of:
1. Starting with an exhaustive list of 159605 BCH codes designed to detect 3 or 4 errors up to length 93, 151, 165, 341, 1023, and 1057.
2. From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes.
<<<

(what's important here is the second part on lengths)

Now, I am no expert on error encoding formats, but I think that bech32 is under optimised for invoices (whose lengths are greater than 71). Related to this, is there a reason why we use hex encoded pubkeys in lightning? Unless I'm missing something, I think bech32 is better to use in this context. Please correct me if I'm wrong.

Have a nice day,
Varunram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181120/eb183d24/attachment-0001.html>