> And you don't get the benefit of the turn-taking approach, which is that > you can have a known state for fee changes. Even if you change it to > have opener always the leader, it still has to handle the case where > incoming changes are not allowed under the new fee regime (and similar > issues for other dynamic updates).
Good point, I hadn't considered that a change from one side might become invalid due to a change from the other side. I think however this can only affect changes that result in other changes no longer being applicable, e.g., changing the number of HTLCs you'll allow on a channel making the HTLC we just added and whose update_add is still in flight invalid. I don't think fee changes are impacted here, since the non-leader only applies the change to its commitment once it gets back its own change. The leader will have inserted your update_add into its stream after the fee update, and so you'll first apply the fee update, and then use the correct fee to add the HTLC to your commitment, resulting in the same state. The remaining edgecases where changes can become invalid if they are in flight, can be addressed by bouncing the change through the non-leader, telling him that "hey, I'd like to propose this change, if you're good with it send it back to me and I'll add it to my stream". This can be seen as draining the queue of in-flight changes, however the non-leader may pipeline its own changes after it and take the updated parameters into consideration. Think of it as a two-phase commit, alerting the peer with a proposal, before committing it by adding it to the stream. It adds latency (about 1/2RTT over the token-passing approach since we can emulate it with the token-passing approach) but these synchronization points are rare and not on the critical path when forwarding payments. >> The downside is that we add a constant overhead to one side's >> operations, but since we pipeline changes, and are mostly synchronous >> during the signing of the commitment tx today anyway, this comes out to >> 1 RTT for each commitment. > > Yeah, it adds 1RTT to every hop on the network, vs my proposal which > adds just over 1/2 RTT on average. Doesn't that assume a change of turns while the HTLC was in-flight? Adding and resolving an HTLC requires one change coming from either side of the channel, implying that a turn change must have been performed, which itself takes 1 RTT. Thus to add an remove an HTLC we add at least 1RTT for each hop. With the leader-based approach, we add 1RTT latency to the updates from one side, but the other never has to wait for the token, resulting in 1/2RTT per direction as well, since messages are well-balanced. > Yes, but it alternates because that's optimal for a non-busy channel > (since it's usually "Alice adds htlc, Bob completes the htlc"). What's bothering me more about the turn-based approach is that while the token is in flight, neither endpoint can make any progress, since the one reliquishing the token promised not to say anything and the other one hasn't gotten the token yet. This might result in rather a lot of dead-air if both sides have a constant stream of changes to add. So we'd likely have to add a timeout to defer giving up the token, to counter dead-air, further adding delay to the changes from the other end, and adding yet another parameter. This is in stark contrast to the leader-based approach, where both parties can just keep queuing updates without silent times to transferring the token from one end to the other. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
