📅 Original date posted:2023-04-06
📝 Original message:
Hi Dustin,
I believe this is the scenario I described in [1]?
I haven't looked at the `announcement_signatures` case yet, but at least
for the `commit_sig` case this should never be an issue. It only means
that sometimes, after sending `splice_locked`, you will receive some
`commit_sig` messages that are for commitments that you don't care about
anymore. You should be able to safely ignore those `commit_sig`. I have
provided more details in the gist linked.
Let me know if I'm missing something, but I believe this is simply an
edge case that implementations need to correctly handle, not a protocol
issue? Or maybe I'm not understanding the scenario correctly?
By the way, I find your notation a bit hard to follow...I think that we
really need to detail the exact message flow (like I did in the linked
gist) to be able to explain protocol issues, otherwise there's always
a risk that people think about a slightly different message flow, which
means we'll just talk past each other...
Cheers,
Bastien
[1]
https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86#multiple-splices-with-racy-splice_locked
Le jeu. 6 avr. 2023 à 02:40, Dustin Dettmer <dustin at koinkeep.com> a écrit :
> Hey,
>
> In testing the `splice_locked` workflow I discovered a race condition
> which is critical we solve correctly. The core problem happens if any
> channel activity occurs in the time after `splice_locked` is sent and
> before `splice_locked` is received.
>
> `splice_locked` is defined as being locked once it is both sent and
> received. It is fairly trivial to build a test case for this -- have a node
> continually spamming payments while `splice_lock`ing is occurring and the
> race condition will trigger relatively often.
>
> The race condition effects two messages in particular: `commitment_signed`
> and `announcement_signatures`. Below is an example of how it occurs with
> commitment but the flow is essentially the same for announcement:
>
> Legend:
> Item -> means sent
> Item <- means received
> Chan X (implies a channel at block height X)
> (Since these happen at different times)
> Splice locked race condition example
> Node A. Node B.
> * Channel starts at block height 100
> splice_locked ->
> <- splice_locked
> <- commitments_signed (Chan 100)
> -> splice_locked
> Node B now considers splice locked (Chan 106)
> <- commitments_signed (Chan 106)
> splice_locked <-
> Node A now considers splice locked (Chan 106)
> commitments_signed <- (Chan 100)
> commitments_signed <- (Chan 106)
> Node A considers the commitments_signed for Chan 100 invalid.
> The commitments_signed for Chan 106 is, however, valid.
> This example uses commitments_signed but remains a problem for any message
> that depends on channel state.
>
> The solution requires the temporary storing of two items:
> * [scid] last_short_channel_id (the pre-splice short channel id)
> * [bool] splice_await_commitment_succcess
>
> After sending & receiving `splice_locked` (so called 'mutual splice lock),
> the last_short_channel_id should be set to the pre-splice short channel id
> and splice_await_commitment_succcess should be flagged to true.
>
> If an `announcement_signatures` is received with an scid matching
> `last_short_channel_id` the message should be ignored and the channel
> connection should not be aborted (as it normally would).
>
> If a `commitment_signed` message is received with the
> tlv splice_info->splice_channel_id set to something other than the
> successfully confirmed splice channel_id, the message should be ignored.
>
> Once a revoke_and_ack is successfully sent OR received,
> `last_short_channel_id` and `splice_await_commitment_succcess` should be
> reset and normal validation of `announcement_signatures` and
> `commitment_signed` should be resumed.
>
> This solves the race condition while preserving as strict a validation of
> messages as possible and removes the need to add new fields to these
> messages.
>
> Cheers,
> Dusty
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230406/058383a0/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:08:32
in reply to nevent1q…qm7t
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:08:32Event JSON
{
"id": "cff627f65516a38160c4a1605bbe24cba594cae58f2fc26173fadfd28a6236b6",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686316112,
"kind": 1,
"tags": [
[
"e",
"e807c06d53d31db1868d82c122d8fbeacc9f4bc716132cf0bd704fb8c0016b94",
"",
"root"
],
[
"e",
"c38e99ac625a44839811d66225fd916e3b010d48f64be7246e158fb56ea4ca08",
"",
"reply"
],
[
"p",
"352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794"
]
],
"content": "📅 Original date posted:2023-04-06\n📝 Original message:\nHi Dustin,\n\nI believe this is the scenario I described in [1]?\n\nI haven't looked at the `announcement_signatures` case yet, but at least\nfor the `commit_sig` case this should never be an issue. It only means\nthat sometimes, after sending `splice_locked`, you will receive some\n`commit_sig` messages that are for commitments that you don't care about\nanymore. You should be able to safely ignore those `commit_sig`. I have\nprovided more details in the gist linked.\n\nLet me know if I'm missing something, but I believe this is simply an\nedge case that implementations need to correctly handle, not a protocol\nissue? Or maybe I'm not understanding the scenario correctly?\n\nBy the way, I find your notation a bit hard to follow...I think that we\nreally need to detail the exact message flow (like I did in the linked\ngist) to be able to explain protocol issues, otherwise there's always\na risk that people think about a slightly different message flow, which\nmeans we'll just talk past each other...\n\nCheers,\nBastien\n\n[1]\nhttps://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86#multiple-splices-with-racy-splice_locked\n\n\nLe jeu. 6 avr. 2023 à 02:40, Dustin Dettmer \u003cdustin at koinkeep.com\u003e a écrit :\n\n\u003e Hey,\n\u003e\n\u003e In testing the `splice_locked` workflow I discovered a race condition\n\u003e which is critical we solve correctly. The core problem happens if any\n\u003e channel activity occurs in the time after `splice_locked` is sent and\n\u003e before `splice_locked` is received.\n\u003e\n\u003e `splice_locked` is defined as being locked once it is both sent and\n\u003e received. It is fairly trivial to build a test case for this -- have a node\n\u003e continually spamming payments while `splice_lock`ing is occurring and the\n\u003e race condition will trigger relatively often.\n\u003e\n\u003e The race condition effects two messages in particular: `commitment_signed`\n\u003e and `announcement_signatures`. Below is an example of how it occurs with\n\u003e commitment but the flow is essentially the same for announcement:\n\u003e\n\u003e Legend:\n\u003e Item -\u003e means sent\n\u003e Item \u003c- means received\n\u003e Chan X (implies a channel at block height X)\n\u003e (Since these happen at different times)\n\u003e Splice locked race condition example\n\u003e Node A. Node B.\n\u003e * Channel starts at block height 100\n\u003e splice_locked -\u003e\n\u003e \u003c- splice_locked\n\u003e \u003c- commitments_signed (Chan 100)\n\u003e -\u003e splice_locked\n\u003e Node B now considers splice locked (Chan 106)\n\u003e \u003c- commitments_signed (Chan 106)\n\u003e splice_locked \u003c-\n\u003e Node A now considers splice locked (Chan 106)\n\u003e commitments_signed \u003c- (Chan 100)\n\u003e commitments_signed \u003c- (Chan 106)\n\u003e Node A considers the commitments_signed for Chan 100 invalid.\n\u003e The commitments_signed for Chan 106 is, however, valid.\n\u003e This example uses commitments_signed but remains a problem for any message\n\u003e that depends on channel state.\n\u003e\n\u003e The solution requires the temporary storing of two items:\n\u003e * [scid] last_short_channel_id (the pre-splice short channel id)\n\u003e * [bool] splice_await_commitment_succcess\n\u003e\n\u003e After sending \u0026 receiving `splice_locked` (so called 'mutual splice lock),\n\u003e the last_short_channel_id should be set to the pre-splice short channel id\n\u003e and splice_await_commitment_succcess should be flagged to true.\n\u003e\n\u003e If an `announcement_signatures` is received with an scid matching\n\u003e `last_short_channel_id` the message should be ignored and the channel\n\u003e connection should not be aborted (as it normally would).\n\u003e\n\u003e If a `commitment_signed` message is received with the\n\u003e tlv splice_info-\u003esplice_channel_id set to something other than the\n\u003e successfully confirmed splice channel_id, the message should be ignored.\n\u003e\n\u003e Once a revoke_and_ack is successfully sent OR received,\n\u003e `last_short_channel_id` and `splice_await_commitment_succcess` should be\n\u003e reset and normal validation of `announcement_signatures` and\n\u003e `commitment_signed` should be resumed.\n\u003e\n\u003e This solves the race condition while preserving as strict a validation of\n\u003e messages as possible and removes the need to add new fields to these\n\u003e messages.\n\u003e\n\u003e Cheers,\n\u003e Dusty\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230406/058383a0/attachment-0001.html\u003e",
"sig": "455908ab5b1aeb95d182ae5ddeab44edb2381ab2abef4046139c354ff3f73af24fb800e159fad7e9ee97329fee36f52d0018b01dd3353b8450d18bf271635554"
}