Author: Lloyd Fournier 2020-03-05 09:56:54
Published on: 2020-03-05T09:56:54+00:00
The discussion revolves around the use of an interactive key generation protocol similar to coin tossing, which generates a uniformly random key. This is compared to MuSig, which is not guaranteed to be uniformly random against a malicious party. The coordination and interaction required to arrange getting into an n-of-n in the first place is discussed, as well as reducing latency by reducing communication rounds. A counter to this is using Taproot with an n-of-n internal key and tapscript that has n `OP_CHECKSIG` operations, so that for normal operation, individual signatures are tossed at each other but MuSig-style signing can be done at termination of the offchain protocol with the n-of-n aggregate key. Another counter is that the aggregate key for a PTLC does not need to be chosen at payment time, and channel members could use the "master" aggregate key they generated by coin tossing at the channel's inception and pseudorandomly randomize it every time they need a new joint key. Overall, it is worth considering whether a protocol benefits from non-interactivity in the key generation stage, and if it doesn't, then coin tossing might be the answer.
Updated on: 2023-06-13T23:59:46.607743+00:00