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

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.

Great share - saving this to make a future video on :)

0 sats \ 0 replies \ @leo 19 Apr

Excellent read

The diagrams illustrating taproot are outstanding.