📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:06:15
in reply to nevent1q…uzvy
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:06:15Event JSON
{
"id": "83cda8f5c5754ec6ddbe70d6feadeb4315cca06c8649dda400bd683e6d9a1fe9",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315975,
"kind": 1,
"tags": [
[
"e",
"dc50ebb4a33ebb68559db83f1f909a9de4df76c851710dee0b49ae8b2ad5f61f",
"",
"root"
],
[
"e",
"131593eab55bd035976c8d96b029d8e62075bcd7dcbc0d91a7b806729beb9432",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-06-28\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e\u003e Rene Pickhardt brought up the issue of latency with regards to\n\u003e\u003e nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin\n\u003e\u003e StackExchange\n\u003e\n\u003e Not explicitly, but that strikes me as more of an implementation level\n\u003e concern. As an example, today more nodes are starting to use replicated\n\u003e database backends instead of a local ed embedded database. Using such a\n\u003e database means that _network latency_ is now also a factor, as committing\n\u003e new states requires round trips between the DBMS that'll increase the\n\u003e perceived latency of payments in practice. The benefit ofc is better support\n\u003e for backups/replication.\n\u003e\n\u003e I think in the multi-signature setting for LN, system designers will also\n\u003e need to factor in the added latency due to adding more signers into the mix.\n\u003e Also any system that starts to break up the logical portions of a node\n\u003e (signing, hosting, etc -- like Blockstream's Greenlight project), will need\n\u003e to wrangle with this as well (such is the nature of distributed systems).\n\nIt is worth mentioning here that the LN protocol is generally not very\nlatency sensitive, and from my experience can easily handle very slow\nsigners (3-5 seconds delay) without causing too many issues, aside from\nslower forwards in case we are talking about a routing node. I'd expect\nrouting node signers to be well below the 1 second mark, even when\nimplementing more complex signer logic, including MuSig2 or nested\nFROST.\n\nIn particular remember that the LN protocol implements a batch\nmechanism, with changes applied to the commitment transaction as a\nbatch. Not every change requires a commitment and thus a signature. This\nmeans that while a slow signer may have an impact on payment latency, it\nshould generally not have an impact on throughput on the routing nodes.\n\nRegards,\nChristian",
"sig": "b4f12a6a11996ee5c1f98a37d0bcab65efc29370a7fa16a4480f7ebfb549e16f539709597dfc714e4d7923c51c41e4e60762ca92f784044b733d083a87a2d477"
}