Merge pull request #24 from dunxen/add-2618

Add 2618

Author: dunxen

_posts/2023-09-15-#1924.md

@@ -6,7 +6,7 @@ pr: 1924
 authors: [benthecarman]
 components: ["ChannelManager", "Channel"]
 host: dunxen
-status: upcoming
+status: past
 commit:
 ---
 
@@ -20,7 +20,7 @@ commit:
 ## Questions
 
 1. Did you have a quick glance or review of the PR?
-1. How do we practically enforce the delay of 100 blocks before sending a `channel_open` for channels with coinbase funding transaction in the PR?
+1. How do we practically enforce the delay of 100 blocks before sending a `channel_ready` for channels with coinbase funding transaction in the PR?
 1. Why do we not need to worry about adding any buffer on top of the 100 block maturation delay? Think in terms of re-orgs.
 1. In the Lightning protocol, it's important that the funding transactions (and all others) are non-malleable (their txids are not malleable).
    Usually we think of transactions solely spending segwit-style UTXOs as being non-malleable. In what sense are coinbase transactions non-malleable?

_posts/2023-09-29-#2618.md

@@ -0,0 +1,38 @@
+---
+layout: pr
+date: 2023-09-29
+title: "Include an `outbound_payment` flag in `MaybeTimeoutClaimableHTLC`"
+pr: 2618
+authors: [TheBlueMatt]
+components: ["ChannelMonitor"]
+host: dunxen
+status: upcoming
+commit:
+---
+
+## Notes
+
+* In [PR 2476] the [`AvailableBalances::balance_msat`] field, which caused confusion due to its strange computation, was removed in favour of
+  using `ChannelMonitor::get_claimable_balances` which is more straightforward for most use-cases and indicates balances claimable by the holder
+  after taking on-chain fees into account.
+* In [PR 2333] the [`Balance::claimable_amount_satoshis`] method was added, which excluded balances that we are unsure can be claimed (i.e. returns `0` for those balances).
+  This makes sense on the surface, however, in the case of forwarding an HTLC, we know that we would either be able to claim the timeout balance from
+  downstream or the preimage balance from upstream. Neither of these would be included in this calculation while the forwarded payment was still pending
+  and not timed out.
+* [PR 2618] (this PR) will include the timeout balance (`MaybeTimeoutClaimableHTLC`) but only in the case of forwarded payments. This offers a more accurate
+  view of the claimable balance.
+
+
+## Questions
+1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or NACK](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
+1. How was the value of the (now removed) `AvailableBalances::balance_msat` field calculated and what was its intended usage?
+1. What do we use instead of `balance_msat` for the above purpose?
+1. Without the use of `balance_msat` how might a developer using LDK calculate an appropriate balance to show to an end-user? 
+1. What should the `HTLCSource` of an outbound payment be? And for a forwarded payment?
+1. What other fluctuations in balance do we still have after this PR for forwarded payments? How might we resolve these in a future PR?
+
+[PR 2476]: https://github.com/lightningdevkit/rust-lightning/pull/2476
+[PR 2333]: https://github.com/lightningdevkit/rust-lightning/pull/2333
+[PR 2618]: https://github.com/lightningdevkit/rust-lightning/pull/2618
+[`AvailableBalances::balance_msat`]: https://github.com/lightningdevkit/rust-lightning/blob/7a63ab77da7e0be35b1c5d87643e5461cd593b94/lightning/src/ln/channel.rs#L69
+[`Balance::claimable_amount_satoshis`]: https://github.com/lightningdevkit/rust-lightning/blob/6016101ac8ff31275f31f68eef8d33e94b19c0b1/lightning/src/chain/channelmonitor.rs#L658