Account for splices in claimable balances #4029
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4029 +/- ##
==========================================
+ Coverage 88.56% 88.77% +0.20%
==========================================
Files 175 176 +1
Lines 129175 129402 +227
Branches 129175 129402 +227
==========================================
+ Hits 114408 114878 +470
+ Misses 12246 11913 -333
- Partials 2521 2611 +90
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
Discussed this one offline, needs the balance stuff to consider splices. |
wpaulino
force-pushed
the
splice-claimable-balances
branch
3 times, most recently
from
3ae60bf to
b5244ee
Compare
| @@ -928,7 +946,11 @@ impl Balance { | |||
| #[rustfmt::skip] | |||
| pub fn claimable_amount_satoshis(&self) -> u64 { | |||
| match self { | |||
| Balance::ClaimableOnChannelClose { amount_satoshis, .. }| | |||
| Balance::ClaimableOnChannelClose { balance_candidates, .. } => { | |||
| // FIXME: Should we report the balance for the currently confirmed splice | |||
There was a problem hiding this comment.
I think this is right. In practice if a splice happens you want to see your balance go down/up in accordance with where the channel is going, not where it was. We need to update the docs to describe this behavior, however.
There was a problem hiding this comment.
Let me know if the docs added are sufficient or if we should clarify a bit more elsewhere
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
wpaulino
force-pushed
the
splice-claimable-balances
branch
from
b5244ee to
0dcabb9
Compare
There are two states in which a pending splice balance should be considered: 1. The channel has closed with a confirmed holder commitment transaction from a splice that did not become locked. The balance from this transaction is reported. 2. The channel is open and has multiple holder commitment transaction candidates that are valid based on the funding transaction that confirms. We want to report the pending splice balance to users while it has yet to become locked, such that they are able to see their funds have moved from their onchain wallet to the channel. We default to reporting the latest splice/RBF balance via `Balance::claimable_amount_satoshis` to mimic how an onchain wallet would behave when reporting unconfirmed balance, otherwise we report the balance for the confirmed splice transaction.
wpaulino
force-pushed
the
splice-claimable-balances
branch
from
0dcabb9 to
a33a7bd
Compare
Similar to
FundedChannel::get_available_balances, we should reflect the correct balance in the monitor based on the current state of a splice. While the channel is still open, we consider our balance to be the lowest balance across all commitment transaction candidates for the current state. Once the channel has a confirmed commitment transaction, we report the balance specific to the correspondingFundingScopebeing spent.