With this patch, we'll fail out earlier in the cycle in case of
some wonky parameters, and not leave zombie payments in the router
which currently are not cleaned up.
Since we want to support AMP payment using a different unique payment
identifier (AMP payments don't go to one specific hash), we change the
nomenclature to be Identifier instead of PaymentHash.
In this commit, we raise the default value for the `MaxParts` field from
1 to 16. This change was motivated by the fact that many users either
forget, or don't even know this field is there in the first place. A
value of 16 was chosen rather arbitraliy (other than power of 2). In
the future, we should tune this value based on the expected number of
payment attempts for a given payment amount.
In this commit we add the ability to intercept forwarded htlc packets
straight from the RPC layer. The RPC layer handles a bidrectional stream
that comminucates to the client the intercepted packets and handles its
response by coordinating with the interceptable switch.
In this commit, we remove the restriction surrounding the largest
invoices that we'll allow a user to create. After #3967 has landed,
users will be able to send in _aggregate_ a payment larger than the
current max HTLC size limit in the network. As a result, we can just
treat that value as the system's MTU, and allow users to request
payments it multiples of that MTU value.
A follow up to this PR at a later time will also allow wumbo _channels_.
However, that requires us to tweak the way we scale CSV values, as post
wumbo, there is no true channel size limit, only the
_local_ limit of a given node. We also need to implement a way for nodes
to signal to other nodes their accepted max channel size.
Modifies the payment session to launch additional pathfinding attempts
for lower amounts. If a single shot payment isn't possible, the goal is
to try to complete the payment using multiple htlcs. In previous
commits, the payment lifecycle has been prepared to deal with
partial-amount routes returned from the payment session. It will query
for additional shards if needed.
Additionally a new rpc payment parameter is added that controls the
maximum number of shards that will be used for the payment.
The default was increased for the main sendpayment RPC in commit
d3fa9767a9729756bab9b4a1121344b265410b1a. This commit sets the
same default for QueryRoutes, routerrpc.SendPayment and
router.EstimateRouteFee.
This commit prepares for more manipulation of custom records. A list of
tlv.Record types is more difficult to use than the more basic
map[uint64][]byte.
Furthermore fields and variables are renamed to make them more
consistent.
In this commitment, we make the `SendToRoute` RPC call consistent with
all the other payment RPCs which will properly adhere to the current max
payment sat limit. This is a prep commit for the future wumbo soft cap
that will eventually land in lnd.
