probabilityFormula() is expected to return an error if capacity is 0, so
we should exclude that case from fuzzing.
Previously it was attempted to avoid this case by seeding the corpus
with an input that had capacity 1. That is not an effective solution
since the fuzzer can still generate an input with capacity 0.
Currently if an incorrect number of timestamps is given, we fail later
on in the GossipSyncer. It makes more sense to fail right away, since we
already do that for incorrect SCID formats (e.g., unsorted or duplicate
SCIDs). There is already a matching check in Encode for incorrect number
of timestamps, so adding this check to Decode makes things symmetric.
We might be trying to send an invoice amount that's greater than the size of the channel, but once you factor in the custom channel logic, an actual HTLC can be sent over the channel to pay that larger payment.
As a result, we'll skip over this check if a have a custom HTLC.
With this commit we make sure the first hop custom records aren't lost
on restart/resume of a payment, so we persist it as part of the
PaymentCreationInfo struct.
This commit extends the forward HTLC intercept response with fields that
can be used in conjunction with a `ResumeModified` action to modify the
intercepted HTLC p2p message.
Introduce `ResumeModified` action to resume standard behavior of a p2p
message with optional modifications as specified by the client during
interception.
- Introduce the field `CustomRecords` to the type `UpdateFulfillHtlc`.
- Encode and decode the new field into the `ExtraData` field of the
`update_fulfill_htlc` wire message.
- Empty `ExtraData` field is set to `nil`.
- Introduce the field `CustomRecords` to the type `UpdateAddHtlc`.
- Encode and decode the new field into the `ExtraData` field of
the `update_add_htlc` wire message.
Because we restrict custom SCID aliases to be in a specific range, we
export the range start and end values so a user of the RPCs we're going
to add in the next commits can adjust their values to fit within the
range.
With the new RPC calls that we are going to add in the next commits, it
will be possible for users to add (local only, non-gossipped) SCID
aliases for channels. Since those will be in the same range as the ones
given out by RequestAlias, we need to make sure that when we generate a
new one that it doesn't collide with an already existing one.
