Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-23 📝 Original message: Hi Michael, > A minor ...
📅 Original date posted:2022-06-23
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220623/e1eb0263/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220623/e1eb0263/attachment.html>;