Taproot and MuSig2 recapellemouton.com/posts/taproot-prelims/
8687 sats \ 5 comments \ @Rsync25 18 Apr 2023 bitcoin
write
preview
related posts
0 sats \ 0 replies \ @IanM 19 Apr 2023
Great share - saving this to make a future video on :)
reply
0 sats \ 0 replies \ @leo 19 Apr 2023
Excellent read
reply
0 sats \ 0 replies \ @0260378aef 18 Apr 2023
The diagrams illustrating taproot are outstanding.
reply
0 sats \ 1 reply \ @shibe 18 Apr 2023
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
reply
10 sats \ 0 replies \ @0260378aef 18 Apr 2023
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.
reply