{"type":"rich","version":"1.0","author_name":"npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsqu","author_url":"https://nostr.ae/npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsqu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-04-04\n📝 Original message:\nHey,\n\nIn testing the `splice_locked` workflow I discovered a race condition which\nis critical we solve correctly. The core problem happens if any channel\nactivity occurs in the time after `splice_locked` is sent and before\n`splice_locked` is received.\n\n`splice_locked` is defined as being locked once it is both sent and\nreceived. It is fairly trivial to build a test case for this -- have a node\ncontinually spamming payments while `splice_lock`ing is occurring and the\nrace condition will trigger relatively often.\n\nThe race condition effects two messages in particular: `commitment_signed`\nand `announcement_signatures`. Below is an example of how it occurs with\ncommitment but the flow is essentially the same for announcement:\n\nLegend:\nItem -\u003e means sent\nItem \u003c- means received\nChan X (implies a channel at block height X)\n(Since these happen at different times)\nSplice locked race condition example\nNode A. Node B.\n* Channel starts at block height 100\nsplice_locked -\u003e\n\u003c- splice_locked\n\u003c- commitments_signed (Chan 100)\n-\u003e splice_locked\nNode B now considers splice locked (Chan 106)\n\u003c- commitments_signed (Chan 106)\nsplice_locked \u003c-\nNode A now considers splice locked (Chan 106)\ncommitments_signed \u003c- (Chan 100)\ncommitments_signed \u003c- (Chan 106)\nNode A considers the commitments_signed for Chan 100 invalid.\nThe commitments_signed for Chan 106 is, however, valid.\nThis example uses commitments_signed but remains a problem for any message\nthat depends on channel state.\n\nThe solution requires the temporary storing of two items:\n* [scid] last_short_channel_id (the pre-splice short channel id)\n* [bool] splice_await_commitment_succcess\n\nAfter sending \u0026 receiving `splice_locked` (so called 'mutual splice lock),\nthe last_short_channel_id should be set to the pre-splice short channel id\nand splice_await_commitment_succcess should be flagged to true.\n\nIf an `announcement_signatures` is received with an scid matching\n`last_short_channel_id` the message should be ignored and the channel\nconnection should not be aborted (as it normally would).\n\nIf a `commitment_signed` message is received with the\ntlv splice_info-\u003esplice_channel_id set to something other than the\nsuccessfully confirmed splice channel_id, the message should be ignored.\n\nOnce a revoke_and_ack is successfully sent OR received,\n`last_short_channel_id` and `splice_await_commitment_succcess` should be\nreset and normal validation of `announcement_signatures` and\n`commitment_signed` should be resumed.\n\nThis solves the race condition while preserving as strict a validation of\nmessages as possible and removes the need to add new fields to these\nmessages.\n\nCheers,\nDusty\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230404/15da6a65/attachment-0001.html\u003e"}