diff --git a/_posts/2023-12-06-#2760.md b/_posts/2023-12-06-#2760.md new file mode 100644 index 0000000..579d060 --- /dev/null +++ b/_posts/2023-12-06-#2760.md @@ -0,0 +1,46 @@ +--- +layout: pr +date: 2024-01-12 +title: "Fix infinite loop when closing a pre-funding channel" +pr: 2760 +authors: [jbesraa] +components: ["channel-establishment", "channel-funding"] +host: jbesraa +status: upcoming +commit: +--- + +## Notes + Creating a channel involves exchanging multiple messages with a + connected peer, which does not always end up successfully. + Specifically, in the current implementation an infinite loop might occur + in the funding step. + This bug was resulted from [ldk/2077]. + + [ldk/2760] Addresses this bug. + + +-------+ +-------+ + | |--(1)- open_channel ---->| | + | |<-(2)- accept_channel ----| | + | |--(3)- funding_created ->| | + | |<-(4)- funding_signed ---| | + | |--(5)- channel_ready --->| | + | A |<-(6)- channel_ready ---| B | + +-------+ +-------+ + +* Channel establishment(v1) is the process of creating a channel with a + connected peer, as detailed here [lightning/bolt02]. + +## 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)? +2. In the original code we have a loop inside `close_channel_internal`, +in which scenario it goes indefintly? +3. Why are we able to drop `force_close_channel_with_peer` from +`close_channel_internal`, and `funding_created` msg from `SignerResumeUpdate`? +4. What was the reasoning for promoting an `OutboundV1Channel` to a +`Channel` before receiving `funding_signed` prior to this PR? Why +do we no only do that promotion after receiving `funding_signed`? + +[lightning/bolt02]: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#channel-establishment. +[ldk/2077]: https://github.com/lightningdevkit/rust-lightning/pull/2077 +[ldk/2760]: https://github.com/lightningdevkit/rust-lightning/pull/2760