CL fails to parse a payment request with unknown tag

[akumaigorodski]

Here's an example of invoice which contains a non-standard tag, CL fails to parse it while it should just ignore unknown tags:

~> ~/lightning/cli/lightning-cli decodepay lntb30m1pw2f2yspp5s59w4a0kjecw3zyexm7zur8l8n4scw674w8sftjhwec33km882gsdpa2pshjmt9de6zqun9w96k2um5ypmkjargypkh2mr5d9cxzun5ypeh2ursdae8gxqruyqvzddp68gup69uhnzwfj9cejuvf3xshrwde68qcrswf0d46kcarfwpshyaplw3skw0tdw4k8g6tsv9e8gu2etcvsym36pdjpz04wm9nn96f9ntc3t3h5r08pe9d62p3js5wt5rkurqnrl7zkj2fjpvl3rmn7wwazt80letwxlm22hngu8n88g7hsp542qpl
{ "code" : -1, "message" : "Invalid bolt11: signature truncated" }

Non-standard tag description can be found here: https://github.com/btcontract/lnurl-rfc/blob/master/spec.md ("When embedded in Lightning invoice lnurl is not bech32-encoded and a letter v is used as tag identifier with decoding rules identical to Description tag d.")

getinfo output

{
  ...
  "version": "v0.7.0rc1-99-gbad0ac6-modded",
  "blockheight": 570019,
  "network": "bitcoin",
  "msatoshi_fees_collected": 0,
  "fees_collected_msat": "0msat"
}

[akumaigorodski]

Not trying to rush things but can you clarify whether this is going to be fixed at some point or considered normal and non-standard tags are discouraged?

[cdecker]

We should probably support it, however we need to make sure we don't miss important things. decodepay should definitely support, but pay should likely reject invoices with unknown fields since the fields may include important instructions without which the payment is meaningless.

[akumaigorodski]

What if a rule is to be established that all non-standard tags are optional? This would make invoice format very flexible and encourage experimentation.

[cdecker]

While that is an option, we can't really do that, which is also why we use the "it's ok to be odd"-rule on the lower level protocol, since we might want to use these extensions in the future.

For example if you create a system that transfers some secret information in the onion to work out, and the sender doesn't know it's supposed to add that information, then we might initiate a payment but ultimately fail because we don't know how to handle the flags in the invoice.

[rustyrussell]

Hmm, spec is clear here:

A reader:

    MUST skip over unknown fields

[cdecker]

My bad, should have checked 😉