CC nostr:nprofile1qqsvh300dvquh50l5t9et2257pxrsk5ndsdgdcdmnnxl9nc0f6l2ejcpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7hn9u55 nostr:nprofile1qqsyy2wzruqsr27rhfzjx0shd6t4l20xwxa33fnj900hwf46y4z9l7gpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxrhwden5te0wfjkccte9ehx7um5wf5kx6pwv3jj7qgewaehxw309a3xcctnw3ezuun9d3shjtnwdaehgu30amx8yr
Discussion
I actually did spend some time thinking about using FROST for payments over LN, where instead of multi-hop forwarding of HTLC, all parties run a signature scheme together to commit changes in an atomic manner. However, I think instead of FROST, MuSig2 might be a better choice.
I initially thought FROST like threshold signatures could have helped, but the problem is that some parties could collude and cheat the other parties - depending on thresholds etc. Therefore I think MuSig2 can work better. It can replace the need of multi-hop HTLCs. This of course takes away privacy goals of LN.
I did write about it a bit here: https://github.com/pool2win/ln-synctomic/ to log my thoughts. It is kind of a brain dump atm, and probably has some glaring mistakes 😃
I would love to join a brainstorming session/chat around this. I think a lot is possible for L2 payments using either MuSig2 or federations using FROST.
taproot channels as proposed in the extension bolts uses Musig2; there’s ongoing work to prove that you can use FROST for one of the keys in a 2/2 Musig2 sig and it still be safe
cc nostr:npub1tr7ndmjkguzupvqhn9clasx4r08q2sklhal4g60844nsnnalw0tqpwnc05 and his team won 1st at nostr:npub1dwah6u025f2yy9dgwlsndntlfy85vf0t2eze5rdg2mxg99k4mucqxz7c52 this year in Austin with their project doing this (assuming security is safe)