I had several successful rebalances, and when I call `rebalancereport` it takes some time to collect info about them.
A possible performance improvement: `rebalancereport` does not call `listpays` for every rebalance one by one, but only once.
In my case, this changes the execution time from ~140 secs to ~7 secs.
It happens that Esplora will send us trimmed blocks (both my personal
instance and blockstream.info, fwiw). Try to detect it without parsing
the entire block on our side.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
It's a bit of duplication but is nonsensical to make a block request if
we couldn't get the block hash.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
This check was introduced to protect against the length being
corrupted but we now get some node_announcements with huge
feature-bits, triggering this rule. Let's skip them instead.
Now it requires the datastore (or datastore.py plugin), if you want
to use runes. The simple reader/writer control lists don't require
that, but for simplicity we always require the runes Python module.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Fix README.md dynamic plugin example (needs keywords, abspath!)
(pointed out by @carnhofdaki).
2. Define magic number we use (suggested by @FreePietje)
the old networkx version 2.3 did try to use `fractions.gcd()` which was
deprecated already and is removed for python 3.9. pulling in networkx
version 2.4 works with python 3.9 while also with the code of this
plugin.
This is required becasue current `lightningd` will not start
when using a non-dynamic plugin.
Since clighting version 0.7.2 is very old, we can safely remove this
code.
This adds an optional paramter to the `feeadjust` method which is `scid`
that will, if set, only adjust one channel. Default remains None which
will adjust all channels.
The new datastore PR now has a generation count; this passes
the tests against that now.
Also copies tests from c-lightning, and adds ugprade test.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This disables scaling of the base fee based on channel distortion and
instead always sets global config base fee.
The rationale behind this is that the base fee is meant to cover the
'fixed risk' of accepting an HTLC. In reality the risk may vary,
but this is unrelated on channel balance distortion but other factors.
We can have dynamic base fee per channel if we implent a better way
of competing and cost/risk coverage for this value.
