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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
