Hi Alex,
This is quite similar to eclair's cluster mode [1] so I can definitely say
it's a great idea :-)
Our rationale was as much reducing the attack surface (we didn't like our
node being directly accessible from the internet) as improving scalability
(handling the constant flow of connections
Hi Alex,
This is quite similar to eclair's cluster mode [1] so I can definitely say
it's a great idea :-)
Our rationale was as much reducing the attack surface (we didn't like our
node being directly accessible from the internet) as improving scalability
(handling the constant flow of connections
Hi Alex,
Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup thousand
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 t
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
