Skip to content

Expose in-flight claim balances #1034

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

Merged
merged 11 commits into from
Sep 15, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 27 additions & 1 deletion lightning/src/chain/chainmonitor.rs
Original file line number Diff line number Diff line change
Expand Up @@ -30,12 +30,13 @@ use chain;
use chain::{Filter, WatchedOutput};
use chain::chaininterface::{BroadcasterInterface, FeeEstimator};
use chain::channelmonitor;
use chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateErr, MonitorEvent, Persist, TransactionOutputs};
use chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateErr, Balance, MonitorEvent, Persist, TransactionOutputs};
use chain::transaction::{OutPoint, TransactionData};
use chain::keysinterface::Sign;
use util::logger::Logger;
use util::events;
use util::events::EventHandler;
use ln::channelmanager::ChannelDetails;

use prelude::*;
use sync::RwLock;
Expand Down Expand Up @@ -140,6 +141,31 @@ where C::Target: chain::Filter,
}
}

/// Gets the balances in the contained [`ChannelMonitor`]s which are claimable on-chain or
/// claims which are awaiting confirmation.
///
/// Includes the balances from each [`ChannelMonitor`] *except* those included in
/// `ignored_channels`, allowing you to filter out balances from channels which are still open
/// (and whose balance should likely be pulled from the [`ChannelDetails`]).
///
/// See [`ChannelMonitor::get_claimable_balances`] for more details on the exact criteria for
/// inclusion in the return value.
pub fn get_claimable_balances(&self, ignored_channels: &[ChannelDetails]) -> Vec<Balance> {
let mut ret = Vec::new();
let monitors = self.monitors.read().unwrap();
for (_, monitor) in monitors.iter().filter(|(funding_outpoint, _)| {
for chan in ignored_channels {
if chan.funding_txo.as_ref() == Some(funding_outpoint) {
return false;
}
}
true
}) {
ret.append(&mut monitor.get_claimable_balances());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm fine with it if users are fine with it, but it seems odd to not relate ClaimableBalances to the channel they correspond to

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I guess if users want it they can get it manually. Lets expose it as-is and see if anyone complains and we can deal with it then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I tend to agree with @valentinewallace. Seems more intuitive / useful and would simplify the interface if a user asked for the balances of a particular channel rather than providing a filter. It would be easier for them to combine balances across all channels (if needed) than figure out which channel each balance belongs to.

What exactly was the use case that led to this request?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

user asked for the balances of a particular channel rather than providing a filter

You should be able to with the current interface?

What exactly was the use case that led to this request?

This PR is targeted at clients who want to display a consistent user balance while a channel close is being confirmed on-chain. If you take the output of ChannelManager::list_channels and calculate live balances from those channels, and add them to the balances (of sensible type) in this PR, you can simply display that as the "user balance".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

user asked for the balances of a particular channel rather than providing a filter

You should be able to with the current interface?

True, but (1) it isn't as intuitive since you need to provide all channel except the one you want and (2) it isn't efficient as you need to iterate through all ignored channels for each channel monitor. The alternative is to have the user provide a funding tx output for the channel of interest and perform a hash map lookup.

That said, given my comment below maybe this is moot.

What exactly was the use case that led to this request?

This PR is targeted at clients who want to display a consistent user balance while a channel close is being confirmed on-chain. If you take the output of ChannelManager::list_channels and calculate live balances from those channels, and add them to the balances (of sensible type) in this PR, you can simply display that as the "user balance".

Ah, I see. I think I may have been confused in that you'd typically use it for balances of closed channels. I guess ChannelManager won't have any ChannelDetails for those? Happy to keep this as is if that's the case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be a bit more clear, I don't think we should approach it as "user queries on a per-channel basis", as that requires the user first asking the ChainMonitor for the list of channels they want to query for. I do think there's an argument to be had for exposing which channel each event corresponds to, but I'm not sure the right way to go about it, and I'm not 100% sure if users will care about that anyway. Open to ideas, or we can leave it as a future work.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. I think I may have been confused in that you'd typically use it for balances of closed channels. I guess ChannelManager won't have any ChannelDetails for those? Happy to keep this as is if that's the case.

Right! The idea is "I want to know my full balance, plus or minus cause balances in lightning are a bit confusing". The answer is "well, I have some off-chain balances, for which I'll ask ChannelManager and I have some on-chain balances, for which I mostly track myself, but there's some 'hiding' in ChainMonitor, which I'll have to ask it about". You don't want to double-count the not-yet-closed channels, so you tell ChainMonitor the list of things that you've already calculated as off-chain balances and let it tell you the rest.

}
ret
}

#[cfg(any(test, feature = "fuzztarget", feature = "_test_utils"))]
pub fn get_and_clear_pending_events(&self) -> Vec<events::Event> {
use util::events::EventsProvider;
Expand Down
Loading