Split prefunded `Channel` into `Inbound`/`Outbound` channels #2077

dunxen · 2023-03-06T08:25:11Z

Currently, funded and unfunded channels are represented by a single Channel struct. This ends up conflating certain state and makes it harder to reason about / less safe to call appropriate methods on Channel to advance state.

This aims to make prefunded vs. funded states more type-safe and logically separated. Prefunded channels are further split into InboundChannels and OutboundChannels. This makes it a compile-time error to call methods only meant for InboundChannels on OutboundChannels and vice versa. This Inbound/Outbound separation for channels using V1 channel establishment is still very useful when it comes to V2 channel establishment (dual-funded channels): it enhances type safety for what actions the V2 channel initiator (Outbound) and non-iniator (Inbound) can take on these objects once they support V2 channel establishment in future work.

Partially addresses #1621

TheBlueMatt · 2023-03-06T23:43:10Z

Does it make sense to drop the ChannelKind enum and instead just actually have three separate maps for channels in the ChannelManager?

TheBlueMatt · 2023-03-06T23:50:52Z

Without having actually reviewed the mega-diff, and aside from that, this LGTM. It would be really nice to split this up into at least like 2 or three commits - maybe first create the context object in a regular channel, then add the trait, then split or something like that?

TheBlueMatt · 2023-03-06T23:51:44Z

We'll want to coordinate on landing this, I think, given its going to conflict with the world. Get some concept ACKs, then all get online at once for an hour or two and get it landed.

dunxen · 2023-03-07T07:46:58Z

Does it make sense to drop the ChannelKind enum and instead just actually have three separate maps for channels in the ChannelManager?

So I started this way actually, and it did seem simpler up until it concerned me a little when we're at the stage where we have the channel promoted when funding is generated/signed, and it seems a bit disjoint handling a second map while you're busy with an OccupiedEntry as there are a quite a few such cases.

I think I will split this out like you suggested (thanks!) and we can see how much more "fluff" the enum causes with matching.

dunxen · 2023-03-08T21:14:05Z

Close to having this split, but with the way I'm doing things with the ChannelContext currently as a field with a getter, I'm really trying to avoid RefCell which seems to want to crop its head up due to constraints with some of the common method signatures. Will try some different patterns, otherwise will push the split (but still kinda broken) changes for ideas.

TheBlueMatt · 2023-03-08T21:53:34Z

Hmm, not sure why interior mutability is cropping up? When we're converting from one channel tor to another we should have full ownership of the object, no?

dunxen · 2023-03-08T22:02:06Z

Hmm, not sure why interior mutability is cropping up? When we're converting from one channel tor to another we should have full ownership of the object, no?

Yeah, so that's fine, it's happening with the methods (ones where there's no converting) and we're trying to maybe read from context via the getter (self.get_context()) in the trait, but maybe we take in &mut self in the signature. Cases like that.

I'll push up some stuff in the morning. Better than my lame explanation :P

TheBlueMatt · 2023-03-08T23:34:05Z

Hmm, yea, not 100% sure why still, would love to look at code.

TheBlueMatt · 2023-03-08T23:35:11Z

Also, can you write up a quick explainer why this is still the right design in dual-funding? I guess we should call the structs InitiatorChannel and InitiateeChannel rather than inbound/outbound? Is there not sufficient functionality overlap between the initiator/initiatee sides that we should just have the same PreFundingChannel?

dunxen · 2023-03-09T06:37:05Z

Also, can you write up a quick explainer why this is still the right design in dual-funding? I guess we should call the structs InitiatorChannel and InitiateeChannel rather than inbound/outbound? Is there not sufficient functionality overlap between the initiator/initiatee sides that we should just have the same PreFundingChannel?

I mean we totally could have just one struct for prefunded channels, as tracking who the initiator is will be kept in the context of the InteractiveTxConstructor struct. However, we still end up with the situation for methods involving accept/open that do not overlap and would be nice to have some type-safety around those two in the form of different structs. For V1 channels there are even more non-overlapping methods. I suppose we don't need to worry too much about improving the status quo for V1 channels in the codebase, then I'm happy to just have one PreFundingChannel.

dunxen · 2023-03-10T14:27:50Z

Lol who knew channel refactoring would be painfully trickier than thought?

With the multi-chan-to-id-map approach there are a bunch of assumptions on the channel_by_id map to be made. It seems quite easy for an uncovered bug to slip through with a refactor.

With the enum-and-single-map approach, it gets pretty ugly, pretty fast.

So taking into account comments above, I'm thinking that we don't mingle V1 and V2 channels in the prefunded state at all. We let V1 channels continue as per usual from start to finish with the Channel struct and then we only introduce a new PendingChannel (or prefunded or whatever) struct for V2 channels which will hold onto the InteractiveTxConstructor object which advances through all its states. Then all the interactive message handling is separate from the V1 channel stuff. (I still feel like splitting that into Initiator/NonInitiator for type-safety around the first bits of the handshake, but just have the pending struct is already way better). We'll keep the trait for sharing the standard behaviour for pending channels.

I feel like there will be less surface area for bugs this way since we'd be touching a lot less. And the case of review and merge conflicts being crazy.

TheBlueMatt · 2023-03-14T20:25:45Z

I mean we totally could have just one struct for prefunded channels, as tracking who the initiator is will be kept in the context of the InteractiveTxConstructor struct. However, we still end up with the situation for methods involving accept/open that do not overlap and would be nice to have some type-safety around those two in the form of different structs.

Ah, okay, yea, I guess that makes sense, I just wanted to check that those methods aren't becoming more symmetric and the design would only make sense for legacy channels. If the design only makes sense for them and not v2 channels I'm okay with the awkwardness for legacy, ultimately up to you, as long as it makes some sense for v2 channels.

With the multi-chan-to-id-map approach there are a bunch of assumptions on the channel_by_id map to be made. It seems quite easy for an uncovered bug to slip through with a refactor.

Hmm, what specifically? We have a bunch of assumptions that channels are there, but that's almost exclusively post-funding. Pre-funding we don't care all that much about a channel - we can't have any HTLCs in it, so its pretty safe to just lose it.

dunxen · 2023-03-20T16:52:18Z

Hmm, what specifically? We have a bunch of assumptions that channels are there, but that's almost exclusively post-funding. Pre-funding we don't care all that much about a channel - we can't have any HTLCs in it, so its pretty safe to just lose it.

Yeah you're right. I've finally settled on that route (ignore the latest WIP push which was the enum route) and it's also turning out to be muuuch simpler to review.

TheBlueMatt · 2023-03-22T02:03:09Z

The channelmanager.rs state as of this PR appears to still have a single map for a Channel, is that intentional?

dunxen · 2023-03-26T10:44:34Z

The channelmanager.rs state as of this PR appears to still have a single map for a Channel, is that intentional?

Sorry, was outdated!

codecov-commenter · 2023-03-26T11:51:16Z

Codecov Report

Patch coverage: 92.47% and project coverage change: -0.01 ⚠️

Comparison is base (74a9ed9) 90.38% compared to head (5d17790) 90.37%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2077      +/-   ##
==========================================
- Coverage   90.38%   90.37%   -0.01%     
==========================================
  Files         106      106              
  Lines       54219    54350     +131     
  Branches    54219    54350     +131     
==========================================
+ Hits        49005    49120     +115     
- Misses       5214     5230      +16

Impacted Files	Coverage Δ
lightning/src/ln/channel.rs	`89.79% <ø> (+0.10%)`	⬆️
lightning/src/ln/functional_test_utils.rs	`87.29% <0.00%> (-0.87%)`	⬇️
lightning/src/ln/channelmanager.rs	`86.73% <91.92%> (-0.02%)`	⬇️
lightning/src/ln/chanmon_update_fail_tests.rs	`98.63% <100.00%> (ø)`
lightning/src/ln/functional_tests.rs	`98.22% <100.00%> (ø)`
lightning/src/ln/onion_route_tests.rs	`98.26% <100.00%> (ø)`
lightning/src/ln/payment_tests.rs	`97.61% <100.00%> (+<0.01%)`	⬆️
lightning/src/ln/shutdown_tests.rs	`98.17% <100.00%> (ø)`

... and 4 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

TheBlueMatt

Didn't super carefully review all the channel motion, but generally LGTM.

lightning/src/ln/channelmanager.rs

dunxen · 2023-03-28T19:34:53Z

There is probably still so

Didn't super carefully review all the channel motion, but generally LGTM.

Thanks for another general review pass. The last commit is admittedly still not great for review. Thinking about splitting it up more. There's also some duplication I'm not super happy with now.

dunxen · 2023-04-04T20:42:47Z

Spent the last while deduplicating some things in the final commit and resolving some nasty borrow conflicts and it's taken way longer than anticipated, but it has made me realise that we probably don't need to worry about generalising things too much.

When we encounter issues with Inbound/Outbound channels those are only ever "Close", but all we ever really need to do is discard and clean up maps. I've been able to simplify some things because of this and will get it up when all the tests are happy. There are a lot of moving parts and I regret touching this lol.

… impl

…el_context` This rename and refactor is so that we can get channel details from a `ChannelContext` which is a common object to all channels.

…ext`

dunxen · 2023-06-14T16:12:26Z

Apologies if I missed some feedback. I had to make some changes specifically around when we promote an OutboundV1Channel to a Channel. @wpaulino pointed out correctly that we should be doing that upon successful handling of funding_signed.

Don’t hesitate to point out something important and obvious I’ve missed after the latest push :)

lightning/src/ln/channelmanager.rs

jkczyz · 2023-06-14T19:31:16Z

lightning/src/ln/channel.rs

-	}
+	/// Returns a HTLCStats about inbound pending htlcs
+	fn get_inbound_pending_htlc_stats(&self, outbound_feerate_update: Option<u32>) -> HTLCStats {
+		let context = self;


There's a couple occurrences of this that aren't necessary. Should reduce the changeset to use self instead.

Yeah I initially did this as a pre-diff to reduce interleaving on a large diff, but ended up breaking it up anyway so can remove.

jkczyz · 2023-06-14T19:34:58Z

lightning/src/ln/channel.rs

+	/// if-we-removed-it-already-but-haven't-fully-resolved-they-can-still-send-an-inbound-HTLC
+	/// corner case properly.
+	pub fn get_available_balances(&self) -> AvailableBalances {
+		let context = &self;


Similarly for this variation.

Will address these in a follow-up I think. I believe they still make the diffs that follow more readable without interleaving.

lightning/src/ln/channelmanager.rs

jkczyz · 2023-06-14T20:52:46Z

lightning/src/ln/channel.rs

+	pub fn is_funding_initiated(&self) -> bool {
+		self.channel_state >= ChannelState::FundingSent as u32
 	}


IIUC, OutboundV1Channel and InboundV1Channel can neither be in this state. Thus, it's fine that we ignore the corresponding maps when writing ChannelManager. As of now Channel may or not be in this state, though. Going forward, what should be represented as a ChannelState variant vs defined by a specific channel struct type? I think preferably we don't have redundant state to avoid inconsistency.

This would make sense just to have in Channel. I'll leave it as is for now and address it in a further "remove redundant state" PR

TheBlueMatt · 2023-06-14T20:26:25Z

lightning/src/ln/channel.rs

+	}
+}
+
+// A not-yet-funded outbound (from holder) channel using V1 channel establishment.


nit: here and on the inbound channel, should be a doc comment, not a comment-comment.

TheBlueMatt · 2023-06-14T20:31:19Z

lightning/src/ln/channelmanager.rs

@@ -5536,7 +5736,7 @@ where
 					), chan),
 					// Note that announcement_signatures fails if the channel cannot be announced,
 					// so get_channel_update_for_broadcast will never fail by the time we get here.
-					update_msg: Some(self.get_channel_update_for_broadcast(chan.get()).unwrap()),
+					update_msg: Some(self.get_channel_update_for_broadcast(&chan.get()).unwrap()),


nit: probably not even worth fixing but this looks unnecessary, the get should return a reference anyway.

True. From when I attempted making it a context 🤦‍♂️

lightning/src/ln/channelmanager.rs

TheBlueMatt · 2023-06-14T21:46:11Z

lightning/src/ln/channelmanager.rs

 			msg,
 		});
-		match peer_state.channel_by_id.entry(chan.channel_id()) {
+		match peer_state.outbound_v1_channel_by_id.entry(chan.context.channel_id()) {


Not really a huge fan of putting this back here, would kinda rather put it in channel_by_id here - indeed we don't have a monitor for this channel yet (we'll get one when we receive a funding_signed) but it does have a "real" channel_id at this point, and we have generated a funding tx which we need to pass a FundingAbandoned event for if we fail.

It's just weird to have funding_signed on Channel when it can only happen on OutboundV1Channel. We'll still get a DiscardFunding event here, so it's just the channel_id that's no longer the temporary one, but that can be documented.

Spoke some offline with @dunxen and I wonder if we shouldn't have three stages here - the pre-funding stage with a temporary_channel_id key as inbound- and outbound-channels, the post-funding stage where we have a channel_id but haven't gotten to the channel_ready exchange as both inbound- and outbound-channels, and the operation stage where a channel is ready.

That would let us enforce the funding_signed, but also more importantly also remove access to the HTLC updates and commitment signing until the channel is actually ready for them.

I don't think this split should go in this PR, though, we're delayed enough as it is, but there's lots more splitting to do in the future.

Looking forward, that further split makes sense and we might introduce enums for the maps if it makes that easier but not super necessary.

I think I will revert to having OutboundV1Channel::funding_signed on Channel::funding_signed so that at least we have temp_chan_id and chan_id consistency in the maps. Adding an extra state in between will clear be a better solution. Luckily there's room to do that in a further PR.

I know it's not ideal in with the splits we have now, but would we be okay with moving funding_signed back to Channel, @wpaulino? :)

I have not reverted that locally yet and have applied the other feedback. So would just like to hear some thoughts.

This commit also adds two new maps to `PeerState` for keeping track of `OutboundV1Channel`s and `InboundV1Channel`s so that further commits are a bit easier to review.

wpaulino

It'd be nice to track all of the follow-up items in an issue so we don't forget and can better determine what should go in this release as well.

wpaulino · 2023-06-15T23:19:48Z

lightning/src/ln/channelmanager.rs

@@ -1695,6 +1715,21 @@ macro_rules! break_chan_entry {
 	}
 }

+macro_rules! try_v1_outbound_chan_entry {


This could just be another arm of the existing try_chan_entry macro, no?

wpaulino · 2023-06-15T23:25:47Z

lightning/src/ln/functional_test_utils.rs

@@ -794,6 +794,17 @@ macro_rules! get_outbound_v1_channel_ref {
 	}
 }

+#[cfg(test)]
+macro_rules! get_inbound_v1_channel_ref {


No big deal, but this was added two commits ago, removed in the previous, and added back here.

wpaulino · 2023-06-15T23:27:22Z

lightning/src/ln/channel.rs

@@ -6265,7 +6265,7 @@ impl<Signer: WriteableEcdsaChannelSigner> InboundV1Channel<Signer> {
 		Ok(chan)
 	}

-	pub fn inbound_is_awaiting_accept(&self) -> bool {
+	pub fn is_awaiting_accept(&self) -> bool {


Could also rename get_funding_outbound_created.

TheBlueMatt

Okayyy, this LGTM, at least enough to merge it. Sadly there's a handful of places in channelmanager where we are only looking at channel_by_id and need to update to look at the other maps. Can you open a followups issue so that we can track these and @wpaulino's comments and make sure we hit at least the bugs before 0.0.116?

close_channel_internal should fallback to force-closure if the channel is in the inbound/outbound sets, though I'm not sure its super critical,
update_partial_channel_config should probably be updated to work on any channel
internal_shutdown should FC any pending channels
do_chain_event needs to call best_block_updated even on unfunded channels so we time out channels if they aren't funded in 2 weeks
peer_connected tries to remove outbound unfunded channels on reconnect but doesn't look at the new outbound map (which, now that I look at it, should be generating a ChannelClosed event, but isn't...ugh we need to consolidate the channel close codepaths)

TheBlueMatt · 2023-06-15T22:12:49Z

lightning/src/ln/channelmanager.rs

+	};
+	($self: ident, $err: expr, $channel_context: expr, $channel_id: expr, PREFUNDED) => {
+		match $err {
+			// We should only ever have `ChannelError::Close` when prefunded channels error.


I mean maybe that's true, but let's definitely fix this in a followup to handle the warn/ignore cases properly.

TheBlueMatt · 2023-06-16T00:50:13Z

lightning/src/ln/channel.rs

+	/// those explicitly stated to be allowed after shutdown completes, eg some simple getters).
+	/// Also returns the list of payment_hashes for channels which we can safely fail backwards
+	/// immediately (others we will have to allow to time out).
+	pub fn force_shutdown(&mut self, should_broadcast: bool) -> ShutdownResult {


Would be nice to move this into the normal channel in the future, then the pre-funding one can just have an abandon method that doesn't take should_broadcast and is clearer.

TheBlueMatt · 2023-06-16T05:26:56Z

lightning/src/ln/functional_tests.rs

@@ -3614,8 +3620,8 @@ fn test_peer_disconnected_before_funding_broadcasted() {
 	nodes[0].node.peer_disconnected(&nodes[1].node.get_our_node_id());
 	nodes[1].node.peer_disconnected(&nodes[0].node.get_our_node_id());

-	check_closed_event!(nodes[0], 1, ClosureReason::DisconnectedPeer);
-	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
+	check_closed_event(&nodes[0], 1, ClosureReason::DisconnectedPeer, false);


ISTM this should be true, right? We should be doing a DiscardFunding here.

TheBlueMatt · 2023-06-16T05:39:46Z

lightning/src/ln/channelmanager.rs

@@ -2166,19 +2257,19 @@ where
 	}

 	/// Helper function that issues the channel close events
-	fn issue_channel_close_events(&self, channel: &Channel<<SP::Target as SignerProvider>::Signer>, closure_reason: ClosureReason) {
+	fn issue_channel_close_events(&self, context: &ChannelContext<<SP::Target as SignerProvider>::Signer>, closure_reason: ClosureReason) {


God there's so many codepaths when closing channels, this called manually, or via something else or....good opportunity to clean this up a ton by unifying the various channel close codepaths.

TheBlueMatt · 2023-06-16T05:40:51Z

lightning/src/ln/channelmanager.rs

@@ -2076,7 +2137,7 @@ where
 		Ok(temporary_channel_id)
 	}

-	fn list_channels_with_filter<Fn: FnMut(&(&[u8; 32], &Channel<<SP::Target as SignerProvider>::Signer>)) -> bool + Copy>(&self, f: Fn) -> Vec<ChannelDetails> {
+	fn list_funded_channels_with_filter<Fn: FnMut(&(&[u8; 32], &Channel<<SP::Target as SignerProvider>::Signer>)) -> bool + Copy>(&self, f: Fn) -> Vec<ChannelDetails> {


This is now only called once, we should probably try to re-condense with list_channels or just drop this and inline it in its callsite.

dunxen mentioned this pull request Mar 6, 2023

Dual-funded channels and Splicing Project Tracking #1621

Open

10 tasks

TheBlueMatt mentioned this pull request Mar 14, 2023

Docs improvements #2100

Merged

douglaz mentioned this pull request Mar 14, 2023

Docs improvements for channel #2104

Merged

jkczyz self-requested a review March 15, 2023 19:10

dunxen force-pushed the 2023-02-splitchannelstate branch from 0ae09d7 to e2dd185 Compare March 20, 2023 13:59

dunxen force-pushed the 2023-02-splitchannelstate branch 2 times, most recently from 7c2f306 to e1d27b7 Compare March 26, 2023 10:44

dunxen marked this pull request as ready for review March 26, 2023 10:47

TheBlueMatt reviewed Mar 28, 2023

View reviewed changes

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

TheBlueMatt added the Seeking Code Review label Mar 28, 2023

wpaulino self-requested a review March 28, 2023 22:32

tnull removed the Seeking Code Review label Mar 30, 2023

dunxen and others added 7 commits June 14, 2023 16:04

Move Channel::get_*_pending_htlc_stats to ChannelContext impl

ed6a5bb

Move Channel::commit_tx_fee_msat to file-level utilities

08ee72b

Move Channel::next_*_commit_tx_fee_msat methods to ChannelContext…

9f4e714

… impl

Move Channel::get_available_balances to ChannelContext impl

60706d6

Convert ChannelDetails::from_channel to `ChannelDetails::from_chann…

25c1ad8

…el_context` This rename and refactor is so that we can get channel details from a `ChannelContext` which is a common object to all channels.

Make ChannelManager::issue_channel_close_events take a `ChannelCont…

e3f0c55

…ext`

Move channel constants up

1012526

dunxen force-pushed the 2023-02-splitchannelstate branch from 5d17790 to 773f785 Compare June 14, 2023 14:35

wpaulino reviewed Jun 14, 2023

View reviewed changes

jkczyz reviewed Jun 14, 2023

View reviewed changes

TheBlueMatt reviewed Jun 14, 2023

View reviewed changes

dunxen and others added 10 commits June 15, 2023 12:51

Introduce InboundV1Channel & OutboundV1Channel

883e056

Move outbound channel constructor into OutboundV1Channel impl

e6c2f04

Move inbound channel constructor into InboundV1Channel impl

baadeb7

Move Channel::force_shutdown to ChannelContext impl

2ea27e0

Refactor channel map update macros for use with ChannelContext

4ad67cf

Create and use methods for counting channels

4b1e286

This commit also adds two new maps to `PeerState` for keeping track of `OutboundV1Channel`s and `InboundV1Channel`s so that further commits are a bit easier to review.

Move outbound channel methods into OutboundV1Channel's impl

4a0cd5c

Move inbound channel methods into InboundV1Channel's impl

637e03a

Rename InboundV1Channel::new_from_req to InboundV1Channel::new

8f93e2d

Rename inbound_is_awaiting_accept() to is_awaiting_accept()

d957f36

dunxen force-pushed the 2023-02-splitchannelstate branch from 773f785 to d957f36 Compare June 15, 2023 20:45

wpaulino approved these changes Jun 15, 2023

View reviewed changes

TheBlueMatt approved these changes Jun 16, 2023

View reviewed changes

TheBlueMatt merged commit ae9e96e into lightningdevkit:main Jun 16, 2023
14 checks passed

dunxen mentioned this pull request Jun 16, 2023

2077 Followups #2360

Closed

6 tasks

dunxen mentioned this pull request Jul 17, 2023

Consider using an enum for channel phase in single PeerState::channel_by_id map #2422

Closed

TheBlueMatt mentioned this pull request Jul 20, 2023

Address outstanding 2077 feedback #2382

Merged

dunxen mentioned this pull request Dec 8, 2023

2760 lightningdevkit/ldk-review-club#27

Merged

Split prefunded Channel into Inbound/Outbound channels #2077

Split prefunded Channel into Inbound/Outbound channels #2077

Conversation

dunxen commented Mar 6, 2023 • edited

TheBlueMatt commented Mar 6, 2023

TheBlueMatt commented Mar 6, 2023

TheBlueMatt commented Mar 6, 2023

dunxen commented Mar 7, 2023

dunxen commented Mar 8, 2023

TheBlueMatt commented Mar 8, 2023

dunxen commented Mar 8, 2023

TheBlueMatt commented Mar 8, 2023

TheBlueMatt commented Mar 8, 2023

dunxen commented Mar 9, 2023

dunxen commented Mar 10, 2023

TheBlueMatt commented Mar 14, 2023

dunxen commented Mar 20, 2023

TheBlueMatt commented Mar 22, 2023

dunxen commented Mar 26, 2023

codecov-commenter commented Mar 26, 2023 • edited

Codecov Report

TheBlueMatt left a comment

Choose a reason for hiding this comment

dunxen commented Mar 28, 2023 • edited

dunxen commented Apr 4, 2023

dunxen commented Jun 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunxen Jun 15, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wpaulino left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Split prefunded `Channel` into `Inbound`/`Outbound` channels #2077

Split prefunded `Channel` into `Inbound`/`Outbound` channels #2077

dunxen commented Mar 6, 2023 •

edited

codecov-commenter commented Mar 26, 2023 •

edited

dunxen commented Mar 28, 2023 •

edited

dunxen Jun 15, 2023 •

edited