One important feature of the MuSig2 design is that, though it's a 2-round protocol (round 1 share, nonces, round 2, share partial sigs), you can actually do the 1st round well ahead of time, *without* already knowing what message is to be signed. This enables a more compact one-round flow in actually signing in real time.

How that actually compares to status quo in terms of performance, assuming everything is set up correctly - I don't know. I'm sure there are a lot of fiddly details there.

0260378aef

bitcoin

Taproot and MuSig2 recap

Rsync25

>Since channel states in Lightning are asymmetric, this also means that this flow will need to happen twice per state update: once to sign the local commitment transaction and once to sign the remote one. But more on that in the next blog post :)

This is an interesting drawback I hadn't thought of before. This means (if I understand it correctly) that completing a Lightning payment will require another round-trip communication between you and your channel partner. I could imagine this leading to slower payments if your latency is high (especially on Tor). Whether it matters in practice remains to be seen though