-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove spurious interactive-tx commit_sig
retransmission
#2966
Conversation
e3cf443
to
c713beb
Compare
c713beb
to
8f586d5
Compare
8f586d5
to
9625a6e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's subtle, hard to be sure all combinations are correctly handled, but LGTM.
eclair-core/src/main/scala/fr/acinq/eclair/channel/fund/InteractiveTxBuilder.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/channel/fund/InteractiveTxBuilder.scala
Outdated
Show resolved
Hide resolved
How do we test the behavior "...if our peer hasn't upgraded and always sends next_commitment_number = current_commitment_number + 1 even when they haven't received our commit_sig, this won't lead to a force-close: we will simply wait for them to send an error, which will never happen." ? If both Bob and Alice send |
eclair-core/src/test/scala/fr/acinq/eclair/channel/states/e/NormalSplicesStateSpec.scala
Outdated
Show resolved
Hide resolved
426f55a
to
be61b2e
Compare
I have rebased to fix conflicts and added de331c8 where I showcase the behavior with non-upgraded nodes. |
be61b2e
to
de331c8
Compare
I'll ask feedback during tonight's spec meeting before merging this PR. If other implementations are fine with this, we'll merge this PR and make an eclair release tomorrow. |
We fully implement lightning/bolts#1214 to stop retransmitting `commit_sig` when our peer has already received it. We also correctly set `next_commitment_number` to let our peer know whether we have received their `commit_sig` or not. We also retransmit `tx_signatures` (and, if requested, `commit_sig`) after sending `channel_ready` in the 0-conf case. This was missing and was a bug.
a4bed35
to
5e35a21
Compare
We've discussed this during yesterday's spec meeting: we have an ACK to release, so I've done a last rebase and we can now merge! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
We fully implement lightning/bolts#1214 to stop retransmitting
commit_sig
when our peer has already received it. We also correctly setnext_commitment_number
to let our peer know whether we have received theircommit_sig
or not.Note that if our peer hasn't upgraded and always sends
next_commitment_number = current_commitment_number + 1
even when they haven't received ourcommit_sig
, this won't lead to a force-close: we will simply wait for them to send anerror
, which will never happen. Their channel will be stuck until they upgrade and sendnext_commitment_number = current_commitment_number
.This change must only be merged once:
remote_commitment_number
#2965next_commitment_number
during splice reconnect lightning-kmp#736 so that users can upgrade to avoid being stuck