Published on: 2016-04-30T05:45:27+00:00
In a discussion about the possibility of nodes getting stuck in an infinite loop while sending each other new HTLCs instead of immediately sending a new SIG, Rusty Russell explains that as long as an HTLC is committed to by both sides, it's locked in. He also notes that until then, the receiver cannot offer it onwards. Furthermore, a node must estimate the deadline for successful redemption for each HTLC it offers and should not offer a HTLC past the deadline.With regards to whether it should be specified that the only valid answer to a signature is either a signature (if there are outstanding changes) or a revocation, Rusty believes that you should be able to pack in as many updates between signatures as you want.In an email exchange, Rusty Russell and Pierre discussed how to handle concurrent signatures. Pierre suggested using an ordering system to resolve conflicts, while Russell explained a simple rule-based approach that involves processing packets in order, updating states when sending or receiving something, and signing a commit tx based on the other side's state at the time. The diagram provided demonstrates the modification of state changes made by nodes during the process, and shows that outstanding changes are acknowledged by sending another SIG, which modifies the other state. Fabrice raised the question of what would happen if both parties decide to send each other a new HTLC instead of immediately sending a new SIG, and whether it could result in an infinite loop where both parties never converge on a commitment tx.The author of the email is discussing how concurrent updates should be handled. They suggest using an ordering system to resolve conflicts by comparing signatures. In this case, if two nodes send each other a signature at the same time, they could agree that the one that sent the "greatest" signature has to immediately resend a new signature including all pending changes.The author then provides a diagram that shows how nodes track two commitment states and the rules nodes must follow when processing packets. When a node sends an ADD HTLC, it modifies the other side's state, but only modifies its own state when it receives an ack covering that ADD HTLC. The ADD HTLC receiver modifies its own state and modifies the other side's state when it sends the next ack. Both nodes have outstanding changes, so they can send another SIG (which acks the received changes, thus modifying the other state). The minimum single-update case is still 1.5 round-trips.The author is trying to understand how to handle concurrent signatures and proposes using an ordering system to resolve conflicts when they occur. The proposed solution involves having two nodes agree on which signature is "greatest" and then having the node that sent the lesser signature immediately resend a new signature including all pending changes. An example scenario is provided where Node A and Node B have conflicting staged changes, but agree to use SIG B0 as the "greatest" signature and proceed with a new signature encompassing all changes. The example concludes with SIG A1 being sent from Node A after the conflict has been resolved.
Updated on: 2023-07-31T18:59:08.863894+00:00