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

BOLT 2: Must not send identical fee changes #618

Open
wants to merge 1 commit into
base: master
from

Conversation

3 participants
@pm47
Copy link
Collaborator

commented Jun 5, 2019

See ElementsProject/lightning#2701 for context.

I went with MUST NOT to be consistent with:

A sending node:

  • MUST NOT send a commitment_signed message that does not include any
    updates.
BOLT 2: Should not send identical fee changes
See ElementsProject/lightning#2701 for context.

I went with *MUST NOT* to be consistent with:

> A sending node:
>  - MUST NOT send a `commitment_signed` message that does not include any
updates.
@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jun 5, 2019

Is it allowed to do update_fee A update_fee B update_fee A before commitment_signed is exchanged and acked, and what would our software do in that case?

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Jun 6, 2019

I think this is not a problem @ZmnSCPxj.
If after update_fee A you sent a corresponding commitment_signed, and do the same after update_fee B and the next update_fee A everything works - you haven't sent duplicates in a row.
If you wait to batch commitment_signed (which you should) you might have sent update_fee A, update_fee B then update_fee A (which is ok since there aren't any subsequent duplicates) and when you update your commit tx you should detect that it hasn't changed since your last commitment_signed and shouldn't send a duplicate commitment_signed.
Does that make sense?

@t-bast t-bast added this to Scheduled in Specification Meeting Agenda Jun 6, 2019

@pm47

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 6, 2019

I realize now that I have made a confusion between no-changes (as in: no update_* messages) and identical (as in: the resulting new commitment is the same as the previous one) commitments.

Depending on the interpretation BOLT 2 doesn't allow no-changes commitments, but it may or may not allow identical commitments.

I would go with the interpretation that BOLT 2 forbids no-changes but allows identical commitments, because it is simpler and there is no point in considering this a spam protection since you can always bump the fee by tiny amounts.

@ZmnSCPxj

This comment has been minimized.

Copy link
Collaborator

commented Jun 6, 2019

@t-bast it seems there would be some flex in how to interpret the spec in this area, as per @pm47 reply above. If I do update_fee A update_fee B update_fee A commitment_signed is this considered "no change" and thus invalid under the current BOLT wording or is this considered "identical, but change still occurred" and thus valid?

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Jun 6, 2019

Good point. I think that update_fee A update_fee B update_fee A commitment_signed would be ok.
Some changes happened, resulting in an identical commitment_signed so I think it should fall under the allow identical commitments rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.