"invalid commitment signature" with Eclair channel #6500
Milestone
Comments
|
From ACINQ side here is what we have: It seems cln wasn't sending signatures. |
|
Here are the logs that @wtogami mentioned (also reported in the Eclair repo). The above seemed to continue for a few days until the invalid commitment signature error: |
This explains why cln wasn't sending sigs. Below is the same diagram as before, starting a little bit earlier and with more details. I believe cln acks rev-334 in its reestablish and the behavior of eclair (not resending rev-334) is correct. |
|
When I tried to produce locally, I got a very strange result. I was not seeing a revoke_and_ack from ACINQ at all: on reconnect, it retransmitted and all worked, but the next HTLC had the same issue. So, is the revoke_and_ack not being sent, or are we somehow not receiving it properly? It seems a pretty fundamental thing, and it's only happening on -rc1 nodes, so I really have to suspect it's us! There were no major demuxing changes, but since I can reproduce this I'll hack something in to log everything we receive to be sure... Nonetheless, this bad signature Shouldn't Happen; I'll look at that too. |
|
Yeah, me too and only with ACINQ:
|
|
OK, pretty sure I've figured out the reason ACINQ doesn't reply with revoke_and_ack: we're sending a splice TLV, even if splicing is not negotiated. (It should be ignoring it, since it's odd, but it could be a spec disagreement, so I'm creating a patch to not send that unless negotiated). Could also point to a bug in ACINQ's (unfinished?) splice code (their node doesn't advertize support). |
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this issue
Aug 7, 2023
This make ACINQ seize up, and not send revoke_and_ack. Eventually, this can cause a bad signature error, should payments go in both directions, which is a separate bug, but this is the trigger. See: ElementsProject#6500 Signed-off-by: Rusty Russell <[email protected]>
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this issue
Aug 7, 2023
This make ACINQ seize up, and not send revoke_and_ack. Eventually, this can cause a bad signature error, should payments go in both directions, which is a separate bug, but this is the trigger. See: ElementsProject#6500 Signed-off-by: Rusty Russell <[email protected]>
rustyrussell
added a commit
that referenced
this issue
Aug 7, 2023
This make ACINQ seize up, and not send revoke_and_ack. Eventually, this can cause a bad signature error, should payments go in both directions, which is a separate bug, but this is the trigger. See: #6500 Signed-off-by: Rusty Russell <[email protected]>
|
This seems to be fixed by #6517 though it's possible that simply unmasked an existing inconsistency. I've closed for now. |
litch
pushed a commit
to litch/lightning
that referenced
this issue
Aug 11, 2023
This make ACINQ seize up, and not send revoke_and_ack. Eventually, this can cause a bad signature error, should payments go in both directions, which is a separate bug, but this is the trigger. See: ElementsProject#6500 Signed-off-by: Rusty Russell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Previous version: v23.05.2
Shortly after upgrading to v23.08rc1 this channel with ACINQ's Eclair node force closed with these errors. Note the Adding HTLC 20 too slow: killing connection and invalid commitment signature.
@grubles reported the same happening with v23.08rc1 and the ACINQ node.
The text was updated successfully, but these errors were encountered: