Skip to content

Do not unnecessarily retransmit commitment_signed in dual funding #1214

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Do not unnecessarily retransmit commitment_signed in dual funding #1214

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6849c33
Do not unnecessarily retransmit `commitment_signed` in dual funding
TheBlueMatt Dec 9, 2024
d8cfa95
Bless the LND SCB force-close request message format
TheBlueMatt Dec 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2482,12 +2482,8 @@ A node:
the last `commitment_signed` message the receiving node has sent:
- MUST reuse the same commitment number for its next `commitment_signed`.
- otherwise:
- if `next_commitment_number` is not 1 greater than the
commitment number of the last `commitment_signed` message the receiving
node has sent:
- SHOULD send an `error` and fail the channel.
- if it has not sent `commitment_signed`, AND `next_commitment_number`
is not equal to 1:
- if `next_commitment_number` is not equal to the commitment number of the
next `commitment_signed` the receiving node will send:
- SHOULD send an `error` and fail the channel.
- if `next_revocation_number` is equal to the commitment number of
the last `revoke_and_ack` the receiving node sent, AND the receiving node
Expand Down Expand Up @@ -2520,7 +2516,8 @@ A receiving node:
- if `next_funding_txid` is set:
- if `next_funding_txid` matches the latest interactive funding transaction:
- if it has not received `tx_signatures` for that funding transaction:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @dunxen points out in https://github.com/lightning/bolts/pull/1160/files#r2022656036, this line isn't necessary anymore and is removed in #1160: it would slightly simplify the splice spec PR to remove this requirement directly in this PR. This section would then become:

    - if `next_funding_txid` matches the latest interactive funding transaction:
      - if `next_commitment_number` is zero:
        - MUST retransmit its `commitment_signed` for that funding transaction.
      - if it has already received `commitment_signed` and it should sign first,
        as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):
        - MUST send its `tx_signatures` for that funding transaction.
      - if it has already received `tx_signatures` for that funding transaction:
        - MUST send its `tx_signatures` for that funding transaction.

- MUST retransmit its `commitment_signed` for that funding transaction.
- if `next_commitment_number` is zero:
- MUST retransmit its `commitment_signed` for that funding transaction.
- if it has already received `commitment_signed` and it should sign first,
as specified in the [`tx_signatures` requirements](#the-tx_signatures-message):
- MUST send its `tx_signatures` for that funding transaction.
Expand All @@ -2529,6 +2526,9 @@ A receiving node:
- otherwise:
- MUST send `tx_abort` to let the sending node know that they can forget
this funding transaction.
- if `next_funding_txid` is not set, and `next_commitment_number` is zero:
- MUST immediately fail the channel and broadcast any relevant latest commitment
transaction.

A node:
- MUST NOT assume that previously-transmitted messages were lost,
Expand Down