Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-01 📝 Original message: Hi Alex, This is a super ...
📅 Original date posted:2022-09-01
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220901/a7c7cf81/attachment.html>;
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220901/a7c7cf81/attachment.html>;