Gursharan Singh
Gursharan Singh
After npm start, none of the methods for server account setup is working for me. Thunderhub version tried: Both v0.12.19 and v0.12.13, same results. I could be doing something wrong...
Regarding most of the rolling window indicators for example SMA, Why isn't the previously calculated SMA Indicator used as an optimization similar to dynamic programming? For e.g in SMA we...
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: 1. Increased memory...
Based on #3057 Introduce two new events i.e. PersistClaimInfo and ClaimInfoRequest. PersistClaimInfo: Indicates that [`ClaimInfo`] should be durably persisted. ClaimInfoRequest: Used to request [`ClaimInfo`] for a specific counterparty commitment transaction....
- [ ] Minimize current set of non-current/previous_commitment reads to counterparty_claimable_outpoints by re-using existing get calls and refactors As part of #3049
Clarified in documentation that users must persist `ChannelMonitor`s and `ChannelMonitorUpdate`s in sequential order, even more so when using async persistence. As part of #1792
We should have granular function level errors. Instead of one big error struct. This serves as documentation as well as allows users to handle specific errors easily.
Currently, every block connection triggers the persistence of all ChannelMonitors with an updated best_block. This approach poses challenges for large node operators managing thousands of channels. Furthermore, it leads to...
* In ChannelManager we have to wait for initial sync to complete. (clarity) * Monitor Updates need to be persisted in sequential fashion (specially when async) (clarity)
Based on #3067 * Add functions to handle ClaimInfoRequest and PersistClaimInfo events. As part of #3049