Author: Dustin Dettmer 2023-04-04 19:45:03
Published on: 2023-04-04T19:45:03+00:00
During the testing of `splice_locked` workflow, an important race condition was discovered which needs to be solved immediately. The issue arises if any channel activity occurs after `splice_locked` is sent but before it is received, and this can trigger the race condition quite frequently. `splice_locked` is considered locked only when it is sent and received. To understand the problem, a test case can be built where a node continually sends payments while `splice_lock`ing is taking place. This race condition affects two messages: `commitment_signed` and `announcement_signatures`. The flow for announcement is similar to commitment.When `splice_locked` is sent, Node B considers the channel spliced (Chan 106). However, if `splice_channel_id` is set to something other than the successfully confirmed splice channel_id, the message should be ignored. Once `revoke_and_ack` is successfully sent or received, `last_short_channel_id` and `splice_await_commitment_success` should be reset, and normal validation of `announcement_signatures` and `commitment_signed` should resume. The solution solves the race condition while preserving strict validation of messages without adding new fields to these messages.
Updated on: 2023-06-03T12:32:20.648034+00:00