Control plane as in dashboard? yea dashboard uses the same relay comms. Have considered moving this a few times to RTC but that'd still use the relay to bootstrap. A backup management-only relay is however potentially good idea now that you got me thinking about it...

Autoupdate is a systemd timer so only enabled by the install.sh path when flagged, if we made it opt-out it wouldn't update existing values, just set new ones where they don't exist

> I'd estimate more than 2 9s

You mean you didn't read install.sh first!?

> should it be our policy to turn off our relays

Only if this does not affect control plane, which I think right now it would by default? (i.e. wallet-to-pub is often the same relay as (clink-)consumer-to-pub? The one thing that can cascade quickly is having no way to get your funds out due to a security-related shutdown.

> should we make auto-updates opt-out instead of opt-in?

As long as there's opting to be done, it is fine, but please, don't be like Obtainium and when you introduce the feature turn it on by default. I had to wipe things due to that one.

> blind trust

I'd estimate more than 2 9s of your users already having that anyway.

optimism

you can update your firewall with a mitigation faster than the devs can write and release a proper patch

Indeed, that moves on to the next question though of how such a thing identifies those zero-days enough to mitigate them.

The kill switch flag seems like the lowest hanging fruit, that might have saved some BTCPay server users. I don't know if CLN funds were actually lost.

Stuff over and above LN is the real surface risk, LNbits has been pwned a few times, BTCPay server recently, extensions for BTCPay in the past, Blink just got hit, CoinOS a few times... 

That informs my thinking on this, there's always hot wallet risk so the the first mitigation is in size and the second is killing things whenever something is suspicious.

One thing I've considered with Pub specifically, since they're discoverable via relay, is should it be our policy to turn off our relays if there's an incident and give people a chance to patch or give us time to diagnose? Problem with that is it makes opt-out a friction path since you'd have to use non-default relays.

Then, should we make auto-updates opt-out instead of opt-in? They're currently opt-in since opt-out is blind trust in our repo and github... but I'm now leaning towards I'd rather catch shit for that than someone naive losing sats they didn't have to.

security

lightning

A Cloudflare WAF for Lightning?

> you can update your firewall with a mitigation faster than the devs can write and release a proper patch

Indeed, that moves on to the next question though of how such a thing identifies those zero-days enough to mitigate them.

The kill switch flag seems like the lowest hanging fruit, that might have saved some BTCPay server users. I don't know if CLN funds were actually lost.

Stuff over and above LN is the real surface risk, LNbits has been pwned a few times, BTCPay server recently, extensions for BTCPay in the past, Blink just got hit, CoinOS a few times... [and Pub has had two](https://stacker.news/items/1548844/r/justin_shocknet?commentId=1548866). These are just ones we know about.

That informs my thinking on this, there's always hot wallet risk so the the first mitigation is in size and the second is killing things whenever something is suspicious.

One thing I've considered with Pub specifically, since they're discoverable via relay, is should it be our policy to turn off our relays if there's an incident and give people a chance to patch or give us time to diagnose? Problem with that is it makes opt-out a friction path since you'd have to use non-default relays.

Then, should we make auto-updates opt-out instead of opt-in? They're currently opt-in since opt-out is blind trust in our repo and github... but I'm now leaning towards I'd rather catch shit for that than someone naive losing sats they didn't have to.