-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Memory] Persist counterparty_claimable_outpoints
out of channel_monitor
#3049
Comments
Outlined approach in https://github.com/orgs/lightningdevkit/discussions/3050 |
This was referenced May 9, 2024
++
|
G8XSU
added a commit
to G8XSU/rust-lightning
that referenced
this issue
Jun 1, 2024
This removes dependency of watched_outputs from per_commitment_claimable_outpoints, it is required since we will no longer have direct access to per_commitment_claimable_outpoints once we start publishing PersistClaimInfo as part of lightningdevkit#3049.
G8XSU
added a commit
to G8XSU/rust-lightning
that referenced
this issue
Jun 1, 2024
This removes dependency of watched_outputs from per_commitment_claimable_outpoints, it is required since we will no longer have direct access to per_commitment_claimable_outpoints once we start publishing PersistClaimInfo as part of lightningdevkit#3049.
G8XSU
added a commit
to G8XSU/rust-lightning
that referenced
this issue
Jun 3, 2024
This removes dependency of watched_outputs from per_commitment_claimable_outpoints, it is required since we will no longer have direct access to per_commitment_claimable_outpoints once we start publishing PersistClaimInfo as part of lightningdevkit#3049.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem:
After every commitment signed,
counterparty_claimable_outpoints
keeps on growing without bounds within a channel_monitor, with a new hashmap entry for each commitment_tx.It poses two problems mainly:
We don't want to keep on storing outpoints which will only be used for revoked_tx / funding_spend, instead we would like to store them in cold storage and read them only when required.
Ideal outcome: After doing this, Ldk's memory footprint should be drastically decreased owing to removed in-memory hashmap entries of
counterparty_claimable_outpoints
counterparty_claimable_outpoints
by re-using existing get calls and refactors [Minimize reads to counterparty_claimable_outpoints #3057 ]PersistClaimInfo
andRequestClaimInfo
[Add PersistClaimInfo and ClaimInfoRequest events #3067]check_spend_counterparty_transaction
andcancel_prev_commitment_claims
to act after we receiveClaimInfo
ClaimInfo
, Re-insertClaimInfo
incounterparty_claimable_outpoints
, so thatget_claimable_balances
can account for it. (Done as part of handle events functions.)The text was updated successfully, but these errors were encountered: