Replies: 4 comments
-
Hey is anybody working on this one? |
Beta Was this translation helpful? Give feedback.
0 replies
-
@Crypt-iQ Up for grabs! 😀 |
Beta Was this translation helpful? Give feedback.
0 replies
-
Ok! Will take this one |
Beta Was this translation helpful? Give feedback.
0 replies
-
Converting this to a discussion. Can be reverted to the issue or a new one opened up if any development is planned for this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, the
ChannelLink
and thechannelArbitrator
leverage an interface (theWitnessBeacon
and its concrete implementation thepreimageBeacon
) in order to notify distinct links when we learn of a new preimage off-chain, or extract a pre-image on chain due to a force close then sweep by the remote party. Atm, the set of stored preimages on disk is never garbage collected. As a result, the storage (though just 32 bytes for each payment) will grow linearly as more payments are forwarded by routing nodes. This isn't an issue now, or in the mid-term, but for longer lived nodes that forward millions of payments over their lifetime, the space may start to become an issue. In order to resolve this, an eviction methodology should be developed for the preimage cache.preimageBeacon
struct (and possibly the underlyingchanneldb.WitnessCache
to support automatic garbage collection of the on disk witnesses. We'll need to strike a balance between retaining them long enough for a link that received an incoming HTLC to pull the HTLC on chain after we learn of the preimage from the outgoing link off-chain, and the duration of time that we'll store each of the witnesses.Beta Was this translation helpful? Give feedback.
All reactions