[bug]: Can not pay bolt11 invoice with feature set to both optional and required

[nordbjorn]

Background

We encountered a bolt11 invoice which our LND nodes could not pay. This is what we saw in the logs: [ERR] RPCS: [/routerrpc.Router/SendPaymentV2]: feature pair exists .

This message seems to map to the ErrFeaturePairExists error code. While digging into the LND code, the best description for this code was here: feature vectors can only set the required or optional feature bit in a pair, not both.

I also looked through the BOLTs, and I do find this requirement: The origin node MUST NOT set both the optional and mandatory bits.

But, then the same BOLT also says that if both the optional and the mandatory feature bits in a pair are set, the feature should be treated as mandatory. .

To me it seems that the invoice was not fully BOLT compliant, but still our LND nodes should have been been able to handle it without errors. Am I wrong somehow?

Would appreciate any insight please.

Your environment

LND v0.18.5-beta

Steps to reproduce

Expected behaviour

The invoice payment should probably succeed, according to the BOLT spec

Actual behaviour

We got an error [ERR] RPCS: [/routerrpc.Router/SendPaymentV2]: feature pair exists

[hieblmi]

I also looked through the BOLTs, and I do find this requirement: The origin node MUST NOT set both the optional and mandatory bits.

Wouldn't this mean that the error is correct since the payee is setting the feature bits?

[nordbjorn]

Wouldn't this mean that the error is correct since the payee is setting the feature bits?

I guess it is a question of interpretation. Maybe you are right. But when I read the bolt, I understand it as the sender should still be able to handle this and just treat the feature as mandatory

[Roasbeef]

Yeah seems like something we should clarify in the spec. My reading isn't the party making the invoice shouldn't set both bits, but the reader should treat it as mandatory if they do.

So we may be a bit stricter that the spec recommends.

This looks to be the method that rejects the feature bit vector during parsing (we read the bytes, then add it to this): https://github.com/lightningnetwork/lnd/blob/cbdd1c22b7edbe89d860d493c3c50c2b90993469/lnwire/features.go#L541-L553

[ellemouton]

I'll take this

[ellemouton]

@nordbjorn - is this appearing after calling lncli payinvoice with the bolt11 invoice string? or are you also calling something like lncli estimateroutefee? I can see where the error would pop up if you are using estimateroutefee or if you are using SendPaymentV2 using the individual proto fields (ie, not just the raw bolt11 invoice) but cannot see how it would pop up just by using lncli payinvoice with the bolt11 invoice.