Join GitHub today
Why add updates to local commitment tx only after `revoke_and_ack`? #569
In BOLT 2 we read:
Why not apply the "add" updates to one's own commitment tx right after sending the
Is there a security reason not to? Or this is a breaking change and can't be applied for historical reasons?
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.
Applying the update to one's own ctx doesn't produce any signature for the counterparty's ctx.
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.