Split the TLV payload processing into parsing and validation #3278

We were weaving in and out of generic code through `fromwire_tlvs` with custom parameters defining the types in that namespace. This hard-wires the parser with the namespace's types. Slowly trying to deprecate `fromwire_tlvs` in favor of this typesafe variant.

Since the parser itself just parses and doesn't include validation anymore we need to put that functionality somewhere. The validation consists of enforcing that the types are in monotonically increasing order without duplicates and that for the even types we know how to handle it.

We wire in the code-generated function, which removes the upfront validation and add the validation back after the `htlc_accepted` hook returns. If a plugin wanted to handle the onion in a special way it'll not have told us to just continue.

We'll need to pass them around anyway, so just make them easier to access by doing a bit more to `process_onionpacket`.

We make the fields in `htlc_accepted_payload` optional (NULL if not present in the payload) and defer validation till after the hook call.

This now enforces all rules for validity, both for the TLV format and checking that the required fields have been provided.

We have consolidated the two functions into a single `route_step_decode` function, and made it static since we call it in the `process_onionpacket` function. We remove the two exposed functions since they're no longer useful.

@niftynei

This function ensures we have all the infos we need to continue if the htlc_accepted hook tells us to. It also enforces well-formedness of the TLV payload if we have a TLV payload. Suggested-by: List Neigut <@niftynei> Signed-off-by: Christian Decker <@cdecker>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Split the TLV payload processing into parsing and validation #3278

Split the TLV payload processing into parsing and validation #3278

Commits on Nov 21, 2019