Skip to content
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

Correctly set next_commitment_number during splice reconnect #736

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Dec 13, 2024

As pointed out in lightning/bolts#1214, when reconnecting a partially signed interactive-tx session, we should set next_commitment_number to the current commitment number if we haven't received our peer's commit_sig, which tells them they need to retransmit it.

More importantly, if our peer behaves correctly and sends us the current commitment number, we must not think that they're late and halt, waiting for them to send error. This commit fixes that by allowing our peers to use the current commitment number when they set next_funding_txid.

Note that we keep retransmitting our commit_sig regardless of the value our peer set in next_commitment_number, because we need to wait for them to have an opportunity to upgrade. In a future commit we will stop sending spurious commit_sig.

This PR must only be merged once ACINQ/eclair#2965 has been deployed on the ACINQ node.

As pointed out in lightning/bolts#1214, when
reconnecting a partially signed `interactive-tx` session, we should
set `next_commitment_number` to the current commitment number if we
haven't received our peer's `commit_sig`, which tells them they need
to retransmit it.

More importantly, if our peer behaves correctly and sends us the
current commitment number, we must not think that they're late and
halt, waiting for them to send `error`. This commit fixes that by
allowing our peers to use the current commitment number when they
set `next_funding_txid`.

Note that we keep retransmitting our `commit_sig` regardless of the
value our peer set in `next_commitment_number`, because we need to
wait for them to have an opportunity to upgrade. In a future commit
we will stop sending spurious `commit_sig`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant