<!DOCTYPE html>
<html><head>
    <meta charset="UTF-8">
</head><body><p>Hello List,<br><br>The reason why we use bech32 for invoice addresses and&#160;raw hex encoded pubkeys and has long puzzled me. Let&#39;s&#160;take&#160;a sample testnet invoice<br><br>&#62;&#62;&#62; &#34;lntb20m1pvjluezhp58yjmdan79s6qqdhdzgynm4zwqd5d7xmw5fk98klysy043l2ahrqspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqfpp3x9et2e20v6pu37c5d9vax37wxq72un98kmzzhznpurw9sgl2v0nklu2g4d0keph5t7tj9tcqd8rexnd07ux4uv2cjvcqwaxgj7v4uwn5wmypjd5n69z2xm3xgksg28nwht7f6zspwp3f9t&#34;<br>&#60;&#60;&#60;<br><br>of length 271 from&#160;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<br><br></p><p>&#62;&#62;&#62;<br>The specific code chosen here is the result of:<br>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.<br>2. From those, requiring the detection of 4 errors up to length 71, resulting in 28825 remaining codes.<br>&#60;&#60;&#60;<br><br>(what&#39;s important here is the second part on lengths)<br><br>Now, I am no expert on error encoding formats,&#160;but I think&#160;that bech32 is under&#160;optimised for invoices&#160;(whose lengths are&#160;greater than 71). Related to this, is there a reason why we use hex encoded pubkeys in lightning? Unless I&#39;m missing something, I think bech32 is better to use in this context.&#160;Please correct me if I&#39;m wrong.<br><br>Have a nice day,<br>Varunram</p></body></html>