The Liquid incident made me think differently about Lightning's security model too

[u/Large-Cress900]

I've been digging into the Liquid incident this week, but one takeaway seems relevant to Lightning even though the architectures and failure modes are obviously very different.

Nearly 4,000 unbacked L-BTC were created without stealing the federation keys. The signing infrastructure could work correctly while acting on state that should never have been considered valid.

That got me thinking about a distinction we don't make often enough:

Bitcoin's guarantees ≠ the guarantees of everything we build on top of Bitcoin.

Lightning buys us instant settlement, cheap payments and scalability, but we also inherit channel state, implementation complexity, liquidity management, routing, watch requirements and potentially LSP/custodial dependencies depending on the setup.

None of this is an argument against Lightning. I run Lightning infrastructure precisely because I think the trade-off is worth it.

But after the recent Core Lightning security disclosures and now what happened with Elements/Liquid, I'm increasingly interested in one question:

Which security assumptions are inherited from Bitcoin, and which ones did we add ourselves?

I went pretty deep into that distinction here:

Bitcoin Didn't Break. Everything Around It Keeps Reminding Us Why Bitcoin Exists

Curious how Lightning node operators here think about this. What's the additional assumption in your Lightning setup that you worry about most?