Hi Alex, This is a super cool project! I've shared some thoughts here in a comment on the draft PR: PR: https://github.com/lightningnetwork/lnd/pull/6843#issuecomment-1234933319
Also I cc'd the lnd mailing list on this reply, perhaps we can move the discussion over there (or in the issue) since this is more of an lnd specific thing. In the future, the lnd mailing list is also probably a better place for lnd architecture specific proposals/discussions. -- Laolu On Thu, Sep 1, 2022 at 10:56 AM Alex Akselrod via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > At NYDIG, we're considering ways to harden large LND deployments. Joost > and I discussed that currently, when external untrusted peers make inbound > connections, LND must verify the identity of the peer during the noise > handshake, and it must do this before enforcing any potential key-based > allow lists. This is done in the same process as the node's other critical > tasks, such as monitoring the chain. > > To reduce the attack area of the main node process, we'd like to propose a > means to optionally separate the peer communication into a separate > process: something like CLN's connectd, running separately, and the > connections would be multiplexed over a single network connection initiated > from the node to the proxy. The core of our current idea is demonstrated in > a draft PR: https://github.com/lightningnetwork/lnd/pull/6843 > > I'd love some early feedback on the general direction of this. If this > would be interesting, I'll build it out into a fully working feature. > > Thanks, > > Alex Akselrod > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
