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

Why add updates to local commitment tx only after `revoke_and_ack`? #569

Open
OrfeasLitos opened this Issue Feb 8, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@OrfeasLitos
Copy link
Contributor

OrfeasLitos commented Feb 8, 2019

In BOLT 2 we read:

[A] node only adds [...] updates to its own commitment transaction when the remote node acknowledges it has applied them via revoke_and_ack.

Why not apply the "add" updates to one's own commitment tx right after sending the update_add? This would bring the communication cost that was pointed out in #472 down to 2 rounds again. (I recognize that this cannot be done for "fulfill" updates.)

Is there a security reason not to? Or this is a breaking change and can't be applied for historical reasons?

@ysangkok

This comment has been minimized.

Copy link
Contributor

ysangkok commented Feb 20, 2019

An update has not been fully applied before it has been "irrevocably committed" (signature received and previous ctx'es revoked).

Why would you sign anything for your counterparty before they have committed to it? Also, the protocol has to function if the connection drops after the add. The current behaviour is to forget about all changes that aren't acked. What would your suggested alternate protocol do? It becomes a lot more complicated if changes aren't locked in on one side first. It wouldn't be nice to have a protocol where, if HTLCs are sent concurrently in both directions, you'd have to validate the commitment_signed against different transactions, to see how much your counterparty received before they sent this commitment_signed!

It is indeed a breaking change, but I don't think your proposed solution works anyway. So I wouldn't call it historical cruft.

@OrfeasLitos

This comment has been minimized.

Copy link
Contributor Author

OrfeasLitos commented Feb 20, 2019

Why would you sign anything for your counterparty before they have committed to it?

Applying the update to one's own ctx doesn't produce any signature for the counterparty's ctx.

The current behaviour is to forget about all changed that aren't acked.

Applying an update to one's own ctx doesn't make one forget their own latest irrevocably commited ctx. In case a connection drops, one can just reset their own ctx to their own latest irrevocably commited ctx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment