BOLT 12: Inconsistent bech32 padding validation across implementations

[erickcestari]

Differential fuzzing across Lightning implementations revealed inconsistent handling of bech32 padding in BOLT 12 offers. Some implementations enforce BIP-173's 4-bit padding constraint while others not.

• Lightning-kmp and Eclair enforce it
• Clightning and rust-lightning do not enforce it

Example of offer with invalid BIP-173 padding: lno1zcss9mk8y3wkklfvevcrszlmu23kfrxh49px20665dqwmn4p72pkseseq

This creates interoperability issues where some nodes reject offers and others accept it. The spec should clarify whether to follow BIP-173 strictly or allow relaxed padding validation.

Should BOLT 12 bech32 encoding follow BIP-173's padding rules?

[Roasbeef]

Seems that we should be examining our various BIP 173 implementations for spec compliance. There might be a gap in test vectors we can help to contribute here.

[TheBlueMatt]

Also presumably applies to BOLT 11, @Roasbeef noted in the meeting.