Mention how to deal with MuSig rounds in multi-hop locks

[jonasnick]

There shouldn't be any additional overhead due to MuSig rounds because the hops will have exchanged nonce commitments already and the left hop knows the transaction that is going to be signed. However, I don't know the BOLTs well enough to be sure that there isn't some corner case where the left hop can't create the transaction "for" the right hop.

[t-bast]

Thanks for the clarification, it looks good to me.

However, I don't know the BOLTs well enough to be sure that there isn't some corner case where the left hop can't create the transaction "for" the right hop.

The left hop is always able to construct the right hop's transaction, that's what enables creating the same commitment transactions trustlessly on both sides to exchanges signatures and revoke previous commitments (this is true in both the current construction and eltoo). So I think you don't need to be concerned about that.

I also had a look at your previous PR (#5) I think it's a very helpful clarification. Were you able to make progress on this too?

[jonasnick]

Thanks for the review (I wasn't able to find you in IRC anymore). Good point about the commitment transactions. Re #5 iirc @apoelstra ACK'd it in private and waxwing thought it was unnecessary complication (but I don't know how close he looked at the proposal), so thanks for providing your opinion.

[t-bast]

I must admit I only looked at #5 from the point of view of multi-hop locks, but I will spend some time on the three other use-cases to form a better opinion.