mirror of
https://github.com/ElementsProject/lightning.git
synced 2025-02-22 22:45:27 +01:00
3c5c22b17a
Lagrang3 points out that if we hit a maximum, we should take into account the reserve. This is true, but it's hard for the caller to do, so change the API to be slightly higher level. Tell "inform" what happened, and it adjust the constraints appropriately. This makes the least assumptions possible (a reserve does *not* mean that the capacity was actually used at that time). We also add a mode to say "this succeeded": for now this does nothing, but it could reduce both min/max capacities, and add capacity in the other direction. This is useful for future payments, but not as useful for the current one. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> |
||
|---|---|---|
| .. | ||
| cln-tracer | ||
| docker | ||
| init | ||
| keys | ||
| msggen | ||
| plugins | ||
| pylightning | ||
| pyln-client | ||
| pyln-grpc-proto | ||
| pyln-proto | ||
| pyln-spec | ||
| pyln-testing | ||
| reprobuild | ||
| sanitizer_suppressions | ||
| bootstrap-node.sh | ||
| cl-repro.sh | ||
| clang-coverage-report.sh | ||
| config-example | ||
| giantnode.py | ||
| lightning-cli.bash-completion | ||
| short_channel_id-to-txid.sh | ||
| startup_regtest.sh | ||