Regenerate PendingHTLCsForwardable on reload instead of serializing #1076
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1076 +/- ##
==========================================
+ Coverage 91.00% 91.22% +0.21%
==========================================
Files 65 65
Lines 33695 34613 +918
==========================================
+ Hits 30663 31574 +911
- Misses 3032 3039 +7
Continue to review full report at Codecov.
|
| // constant as enough time has likely passed that we should simply handle the forwards | ||
| // now, or at least after the user gets a chance to reconnect to our peers. | ||
| pending_events_read.push(events::Event::PendingHTLCsForwardable { | ||
| time_forwardable: Duration::from_secs(2), |
There was a problem hiding this comment.
Do we still expect the user to wait between "now + 2 time forwardable" and "now + 5 * time forwardable" following PendingHTLCsForwardable doc ? Not sure if it makes sense to wait at least 5 * after reload as all pending HTLCs have been normalized in the same period due to the serialization. If yes, maybe doc could suggest that.
There was a problem hiding this comment.
Yea, we haven't changed the docs here, but we would have to do something other than just change the docs - a user cannot determine just by looking at a PendingHTLCsForwardable whether it was created during startup or at runtime, so I dunno if we want to put that complexity on the user. In the future we can/should just do the randomization ourselves, IMO, now that we have a generic random value interface, but that's a bigger change.
When we are prepared to forward HTLCs, we generate a PendingHTLCsForwardable event with a time in the future when the user should tell us to forward. This provides some basic batching of forward events, improving privacy slightly. After we generate the event, we expect users to spawn a timer in the background and let us know when it finishes. However, if the user shuts down before the timer fires, the user will restart and have no idea that HTLCs are waiting to be forwarded/received. To fix this, instead of serializing PendingHTLCsForwardable events to disk while they're pending (before the user starts the timer), we simply regenerate them when a ChannelManager is deserialized with HTLCs pending. Fixes lightningdevkit#1042
TheBlueMatt
force-pushed
the
2021-09-forwardable-regen
branch
from
8b956e9 to
0fcc34b
Compare
|
Squashed with no diff, will take after CI, opened issue to track randomization in RL at #1101. |
When we are prepared to forward HTLCs, we generate a
PendingHTLCsForwardable event with a time in the future when the
user should tell us to forward. This provides some basic batching
of forward events, improving privacy slightly.
After we generate the event, we expect users to spawn a timer in
the background and let us know when it finishes. However, if the
user shuts down before the timer fires, the user will restart and
have no idea that HTLCs are waiting to be forwarded/received.
To fix this, instead of serializing PendingHTLCsForwardable events
to disk while they're pending (before the user starts the timer),
we simply regenerate them when a ChannelManager is deserialized
with HTLCs pending.
Fixes #1042