Implement multi-part payments (MPP) sending support #3809
Commits on Jul 14, 2020
-
paymod: Allow callers to opt out of shadow routing amount fuzzing
With MPP we require that the sum of parts is equal to the `total_msat` amount declared in the onion. Since that can't be changed once the first part arrives we need a way to disable amount fuzzing for MPP.
-
tlvstream: Allow overwriting an already set value
This is necessary in the next commit to override the total_msat that is being delivered to the destination.
-
paymod: Don't assume that the first payment was executed at all
With the `presplit`-modifier we actually skip execution of the root altogether which results in the root not having a result at all. Instead we should use the result returned by `payment_collect_result`.
-
mpp: Add the presplit MPP modifier
Changelog-Added: The MPP presplit modifier splits large payments into 10k satoshi parts to maximize chances of performing the payment and to obfuscate the overall amount being sent.
-
paymod: Not having a result doesn't mean we failed at getroute
Specifically if we split, there is no result, but we shouldn't add a failure message.
-
retrymod: Reset retry counter if parent is a split
If the parent is a split we have new payment parameters, and want to perform a number of attempts with those.
-
paymod: Implement adaptive splitter
This modifier splits a payment that has been attempted a number of times (by a modifier earlier in the mod chain) and has failed consistently. It splits the amount roughly in half, with a but if random fuzz, and then starts a new round of attempts for the two smaller amounts.
-
Changelog-Added: The adaptive multi-part payment modifier will split payments that are failing due to their size into smaller parts, and re-attempted.
-
mpp: Add CLI option to opt-out of multi-part payments
Several tests are not well-suited for mpp, so I added a CLI option to opt-out of the MPP support at startup time.
-
mpp: Detect if destination supports MPP from invoice and abort early
We abort on the root since that is the coordination point for all parts of the payment.
-
mpp: Lower amounts below the presplit amount
Some tests were failing because they were running into the presplit modifier and then surprised that the payment got split.
-
mpp: Consider an abort as the payment being finished
If one part sets the root to be aborted, there is little point in continuing to wait for the remainder, return to the caller immediately.
-
retrymod: Make retry modifier slightly more verbose
I found it rather useful to trace how a payment is getting retried in the logs.
-
ld: We might not have a failing channel if localfail and sendonion
This happens to be an edge case with the way we use `sendonion` in MPP. `sendonion` does not attempt to recover the route even if we supply the shared secrets (it'd require us to map forwarding channels to the nodes etc), so `failnode` will always be unset, unless it is the first hop, which gets stored. This is not a problem if it weren't for the fact that we don't store the partial route, consisting solely of the channel leading to the first hop, therefore the assertion that either both are NULL or both aren't fails on the first hop. This went unnoticed since with MPP we have more concurrent payments in flight, increasing the chances of a exhausted first hop considerably.
-
pytest: Disable MPP sending for 4 tests
These mostly deal with exact HTLC counts, and fixed number of attempts to conclusion, so the randomization that MPP adds is not desirable.
-
pytest: Add an adaptive MPP test
This exercises something that is simply not possible without MPP, i.e., the bundling of multiple paths to get sufficient capacity to perform the payment.
-
plugin: Fix a memory leak and a missing dereference in listconfigs
`listconfigs` calls were setting the description twice and was using the pointer to the boolean value as the boolean value, resulting in always returning `true`.
-
