experimental: Add extra-tlv support to keysend and cli option to allow extra TLV types #4610
Conversation
lightningd/invoice.c
Outdated
| /* If we opened an array at all, now is the time to close it. */ | ||
| if (prevtype != 0) | ||
| json_array_end(stream); | ||
| json_object_end(stream); |
There was a problem hiding this comment.
BTW, JSON schemas has taught me that variable member names are an anti-pattern. So make extra_tlvs an array of objects, with each object "type": u64, "data": hex? Code will be simpler too...
There was a problem hiding this comment.
The main issue here is that the spec technically allows a field to be present multiple times, hence the TLV-type-to-array-of-values indirection. More than happy not to support this :-)
There was a problem hiding this comment.
Sure, then you just have duplicate fields:
[ {"type": 8, "data": "001122"}, {"type": 8, "data": "00112233"} ]
There was a problem hiding this comment.
Actually, they can but it's invalid:
- MUST order `tlv_record`s in a `tlv_stream` by strictly-increasing `type`,
hence MUST not produce more than a single TLV record with the same `type`
And:
- if decoded `type`s are not strictly-increasing (including situations when
two or more occurrences of the same `type` are met):
- MUST fail to parse the `tlv_stream`.
There was a problem hiding this comment.
Right, I was going by the validation code, should have checked the spec itself :-)
plugins/keysend.c
Outdated
| @@ -150,6 +163,9 @@ static struct command_result *json_keysend(struct command *cmd, const char *buf, | |||
| p_opt_def("exemptfee", param_msat, &exemptfee, AMOUNT_MSAT(5000)), | |||
| #if DEVELOPER | |||
| p_opt_def("use_shadow", param_bool, &use_shadow, true), | |||
| #endif | |||
| #if EXPERIMENTAL_FEATURES | |||
| p_opt("extra-tlvs", param_extra_tlvs, &extra_fields), | |||
There was a problem hiding this comment.
We usually use _ not - in JSON, or omit it altogether?
There was a problem hiding this comment.
Removed altogether since I don't like the underscores at all, especially when using the command line.
|
Ok, addressed the comments by removing the dash in the option and by making the dict-of-lists into a list-of-dicts which I agree is much more flexible and easier to code as well. See the range-diff here |
|
Not sure this should be tagged for v10.0.1 since it's not a bugfix, but pinging @niftynei now? |
|
Trivial rebase to fix conflict. Ack 794f8d3 |
Incoming HTLCs are rejected by the HTLC logic if the payload contains an even type that `lightningd` doesn't recognize. This is to prevent us from accidentally accepting a payment that has extra semantics attached (for example if we get a keysend payment and don't know what to do with the TLV field containing the message we should reject it, otherwise the overall semantics of the message delivery fail).
We want to show the fields in the invoice_payment hook.
So far we didn't need this since we were adding them in the correct order. Now we have multiple possible origins so we better sort them.
Changelog-Added: keysend: You can now add extra TLVs to a payment sent via `keysend`
This is because we might allow the main daemon to transparently handle these extra TLVs too.
This is an experimental change to the way we handle unknown TLVs in the main daemon and the
keysendplugin:invoice_paymenthook. This allows plugins to extract and react to the extra TLV fields that were not handled internally yet.keysendplugin to inject these extra TLV fields into the destination TLV, representing the write path of this changekeysendreacts to unknown even TLV types: previously it'd throw up its arms and give up, now it does its preimage extraction and invoice creation logic, then hands off to other plugins. This allows us to incrementally build things like messaging without burdening each plugin to implement this logic over and over again. More in the way of a chain of responsibility rather than simple fail-overAll of this is still guarded behind
--experimental-featuresflag for now since it changes a bit of the logic, but it should only ever impact thenoiseplugin which was doing this itself.I kept the two fixups unmerged, since they are just the gen-files caused by the previous commit, to facilitate reviews.