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

Fee requirement for closing_signed is unclear #499

Open
TheBlueMatt opened this Issue Oct 31, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@TheBlueMatt
Contributor

TheBlueMatt commented Oct 31, 2018

closing_signed only requires that no HTLCs remain in either commitment transaction, but then goes on to say that fee_satoshis must be less than or equal to the base fee of the "final commitment transaction". It is, however, not clear which commitment transaction it references especially if you have in-flight update_fee updates waiting on the full commitment dance. eg in case of async message delivery:

update_fee        -.
commitment_signed -.
                  <-    shutdown
update_fee         >
commitment_signed  >

SHOULD A now have to send its closing_signed? It has no HTLCs in either commitment transaction, but has different commitment transactions here. And if it should, which fee does it have to meet?

I guess there are two obvious solutions, change the closing_signed SHOULD timing to say that the two commitment transactions have to be the same tx number (which seems way simpler), or clarify which fee needs to be met.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Oct 31, 2018

Delay closing_signed until update_fee exchanges complete
See lightningnetwork/lightning-rfc#499
for a bit more about the ambiguity we're addressing here.

Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Oct 31, 2018

Delay closing_signed until update_fee exchanges complete
See lightningnetwork/lightning-rfc#499
for a bit more about the ambiguity we're addressing here.

Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Nov 2, 2018

Delay closing_signed until update_fee exchanges complete
See lightningnetwork/lightning-rfc#499
for a bit more about the ambiguity we're addressing here.

Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Nov 3, 2018

Delay closing_signed until update_fee exchanges complete
See lightningnetwork/lightning-rfc#499
for a bit more about the ambiguity we're addressing here.

Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.
@nayuta-gondo

This comment has been minimized.

Contributor

nayuta-gondo commented Nov 14, 2018

change the closing_signed SHOULD timing to say that the two commitment transactions have to be the same tx number (which seems way simpler),

I agree to try to strict the conditions.
However, the condition that both tx numbers(commitment numbers?) are the same is meaningless.
For example, when the sequence in the figure below is completed, the status of the commitment transaction matches. But both commitment numbers do not match.
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation

I think that closing_signed should be sent in the following state.

  • There are no HTLCs on both sides.
  • There is no pending update_fee on both sides.
  • There is only one valid (non-revoked) commitment transaction on both sides.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment