From contact at varunram.com Tue Nov 20 17:33:59 2018 From: contact at varunram.com (Varunram Ganesh) Date: Tue, 20 Nov 2018 23:03:59 +0530 (IST) Subject: [Lightning-dev] Invoice Address Format Message-ID: <253946303.14656.1542735239405@privateemail.com> 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: