Hi Michael, > A minor point but terminology can get frustratingly sticky if it isn't > agreed on early. Can we refer to it as nested MuSig2 going > forward rather than recursive MuSig2?
No strong feelings on my end, the modifier _nested_ is certainly a bit less loaded and conceptually simpler, so I'm fine w/ using that going forward if others are as well. > Rene Pickhardt brought up the issue of latency with regards to > nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin > StackExchange Not explicitly, but that strikes me as more of an implementation level concern. As an example, today more nodes are starting to use replicated database backends instead of a local ed embedded database. Using such a database means that _network latency_ is now also a factor, as committing new states requires round trips between the DBMS that'll increase the perceived latency of payments in practice. The benefit ofc is better support for backups/replication. I think in the multi-signature setting for LN, system designers will also need to factor in the added latency due to adding more signers into the mix. Also any system that starts to break up the logical portions of a node (signing, hosting, etc -- like Blockstream's Greenlight project), will need to wrangle with this as well (such is the nature of distributed systems). > MuSig2 obviously generates an aggregated Schnorr signature and so even > nested MuSig2 require the Lightning protocol to recognize and verify > Schnorr signatures which it currently doesn't right? Correct. > So is the current thinking that Schnorr signatures will be supported first > with a Schnorr 2-of-2 on the funding output (using OP_CHECKSIGADD and > enabling the nested schemes) before potentially supporting non-nested > MuSig2 between the channel counterparties on the funding output later? Or > is this still in the process of being discussed? The current plan is to jump straight to using musig2 in the funding output, so: a single aggregated 2-of-2 key, with a single multi-signature being used to close the channel (co-op or force close). Re nested vs non-nested: to my knowledge, if Alice uses the new protocol extensions to open a taproot channel w/ Bob, then she wouldn't necessarily be aware that Bob is actually Barol (Bob+Carol). She sees Bob's key (which might actually be an aggregated key) and his public nonce (which might actually also be composed of two nonces), and just runs the protocol as normal. Sure there might be some added latency depending on Barol's system architecture, but from Alice's PoV that might just be normal network latency (eg: Barol is connecting over Tor which already adds some additional latency). -- Laolu
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
