Currently e.g. Acinq is generating invoices in their Phoenix wallet that advertises with a placeholder feature bit 149 for trampoline support.
Parsing a Bolt11 invoice with this feature bit set will overflow in the Bolt11PaymentRequest.FeatureBits field, as it makes use of an enum that does not support that many distinct features. In fact due to the overflow it will set the (unrelated) feature bit 21 instead.
See here for a live-demo of the overflow where a Bolt11 invoice containing feature bit 149 will overflow to set feature bit 21.
One possible solution that does not break back-wards compatibility could be to limit the existing FeatureBits field to only the first 62 feature bits ensuring it does not overflow, and then add a RawFeatureBits field that uses a BitArray as backing allowing for more distinct feature bits.
I can work on a PR for this but just want to make sure that the general approach has a chance of being accepted by the maintainers.
Currently e.g. Acinq is generating invoices in their Phoenix wallet that advertises with a placeholder feature bit
149for trampoline support.Parsing a Bolt11 invoice with this feature bit set will overflow in the
Bolt11PaymentRequest.FeatureBitsfield, as it makes use of an enum that does not support that many distinct features. In fact due to the overflow it will set the (unrelated) feature bit21instead.See here for a live-demo of the overflow where a Bolt11 invoice containing feature bit
149will overflow to set feature bit21.One possible solution that does not break back-wards compatibility could be to limit the existing
FeatureBitsfield to only the first 62 feature bits ensuring it does not overflow, and then add aRawFeatureBitsfield that uses aBitArrayas backing allowing for more distinct feature bits.I can work on a PR for this but just want to make sure that the general approach has a chance of being accepted by the maintainers.