> if someone finds a new exploit

I don't think you'll know about it when someone **finds** an exploit, at least not before it is used, unless when it is found by one of the novel your-vulns-are-my-attention-grab 1337 hackers that have recently been elevated to the greatest heroes of the Bitcoin space and just explain attacks in github issues.

I'm making progress on a defense framework against the latter retardation, because it is completely out of control: "famous bitcoiners" are now the #1 enemy to your sats, as are public repos. After all, you can bet your sats that every half-organized blackhat with zero real skills but a huge `.skills` has an offense framework now.

The whitelist-only approach is definitely necessary in some environments, but I think at odds with the use of *most* Lightning nodes since its value is in openness. Strike and I believe CashApp did and may still do whitelist-only peers, but also somewhat unique cases being exchanges.

I know others have used proxy nodes, where their main node only peers with other edge nodes they operate. 

Clankers definitely make it easier to build a whitelist, but what's whitelisted today in an open network may still need to be blacklisted tomorrow if someone finds a new exploit.

justin_shocknet

I think that you ought to put the clanker on the analysis side, but on the live path I'd do it the same way as you'd configure a WAF: close everything then enable by narrow exception. Then you monitor mostly where you're too strict.