Olaoluwa Osuntokun <laol...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
