Update multi-hop-locks to Musig2 #29
Conversation
There was a problem hiding this comment.
Good stuff, thank you!
but we don't need to know the exact formulas.
Agree. I tried to simplify this even further, because many of the details aren't really necessary. Pushed these changes here https://github.com/jonasnick/scriptless-scripts/commits/musig2-multi-hop-locks-jonasnick. Feel free to have a look and cherry-pick, otherwise I can also propose this as a separate PR.
"you were right in our recent discussions, the protocol does introduce a message from the right participant to the left one, which means 0.5 additional RTT compared to the current lightning protocol"
We shouldn't discuss these things while partying at Bitcoin Beach. I was actually arguing that it does not introduce 0.5 additional RTT :D. But I don't think this writeup is sufficient for answering this because it does not mention how the PTLCs are actually added to the transaction, which also requires signatures. The existing signatures in the writeup are merely about spending from PTLCs to illustrate the mechanism behind multi-hop-locks. If it's not to complex it would generally be interesting to also explain the update mechanism in more detail.
Musig2 will always be preferred over Musig, so the scriptless script multi-hop-locks construction should use it.
t-bast
force-pushed
the
musig2-multi-hop-locks
branch
from
bcc4d06 to
82b4819
Compare
|
Thanks, I applied all of your changes and squashed, we can indeed get rid of the nonces and the formulas and it's even simpler!
I think I finally see why (and it's not only because of beers, sun and jetlag 😄), I started the discussion on the mailing list and zman pointed out that AJ explained a long time ago that if we used separate signatures instead of musig, we could have the offerer send the partial sig (instead of having to wait for a partial sig from the receiver). In our diagram, it basically means that we don't need the arrows going from right to left in the update phase. Even better, what AJ proposed was the best of both worlds: we can have both musig and a script path with separate signatures, and get the data we need to spend the musig part outside of the critical path (so we can eventually spend the musig output, but we can also forward the PTLC faster because we could spend it via the script path if necessary). This is great! However I still think PTLCs on the current lightning protocol will require an additional round-trip because of details in the update protocol and the fact that transaction are assymmetrical...but I may be missing something, it's still too early to tell for sure!
I'm trying to finalize those details in the mailing list post I shared, if the result doesn't need too many details of the current lightning messages it's a good idea to summarize them here. |
|
Excellent, thank you (also for your additional fixes). I had known about this idea to use single signer adaptors, but I was unaware that it would strip a half roundtrip! To convince myself that this works I adapted the diagram. I'll open a WIP PR with it. |
Musig2 will always be preferred over Musig, so the scriptless script multi-hop-locks construction should use it.
I tried to ensure this was compatible with #24, let me know if I missed something. One subtlety it introduces compared to the previous version is that each participant's (partial) public nonce depends on the tweak, so I made this dependency explicit (without detailing the calculation). This doesn't change the protocol itself as the tweaks are shared beforehand (in the setup phase).
Overall I didn't detail how Musig2 components are calculated (aggregated public key, nonces, etc).
It feels like we simply need to make the dependencies between variables explicit to ensure the protocol works, but we don't need to know the exact formulas.
@jonasnick you were right in our recent discussions, the protocol does introduce a message from the right participant to the left one, which means 0.5 additional RTT compared to the current lightning protocol. I need to do more thinking on that, but you're probably right that we cannot get rid of it, as the left participant needs to wait for a partial signature from the right participant before finalizing the addition of that output otherwise it's unsafe.