Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-28 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2022-06-28
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> 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).
It is worth mentioning here that the LN protocol is generally not very
latency sensitive, and from my experience can easily handle very slow
signers (3-5 seconds delay) without causing too many issues, aside from
slower forwards in case we are talking about a routing node. I'd expect
routing node signers to be well below the 1 second mark, even when
implementing more complex signer logic, including MuSig2 or nested
FROST.
In particular remember that the LN protocol implements a batch
mechanism, with changes applied to the commitment transaction as a
batch. Not every change requires a commitment and thus a signature. This
means that while a slow signer may have an impact on payment latency, it
should generally not have an impact on throughput on the routing nodes.
Regards,
Christian
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> 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).
It is worth mentioning here that the LN protocol is generally not very
latency sensitive, and from my experience can easily handle very slow
signers (3-5 seconds delay) without causing too many issues, aside from
slower forwards in case we are talking about a routing node. I'd expect
routing node signers to be well below the 1 second mark, even when
implementing more complex signer logic, including MuSig2 or nested
FROST.
In particular remember that the LN protocol implements a batch
mechanism, with changes applied to the commitment transaction as a
batch. Not every change requires a commitment and thus a signature. This
means that while a slow signer may have an impact on payment latency, it
should generally not have an impact on throughput on the routing nodes.
Regards,
Christian