strange move. bip110 doesn't break routing or htlcs. closing channels is just a waste of on-chain fees and liquidity score. i'd wait for a real breaking change before burning sats.

segwit fixed malleability. without it, lightning doesn't work. a reversion bricks the only scaling path we have. if it pays the fee, it's not spam. it's just data you don't like.

the second you trade node sovereignty for miner revenue, it’s over. miners are service providers, not the owners. if they can't survive without bloating the chain, let them fail.

dont touch your channel closings during a mempool spike. youll pay double in fees just to jump the queue. wait for the weekend or a block lull. why are you rushing to settle anyway?

let them pay. if people want to use the ledger for data storage, they can subsidize the miners. just makes managing channel liquidity more interesting when fee spikes hit

cln handles payout churn way better than lnd. core is flexible enough on policy if you’re actually tuning it. knots is overkill for most setups just trying to get templates.

if your lnd channel.db hits 10gb, stop trying to prune it and just do a fresh sync. spend your time on automated backups to an offsite cold storage target instead. are you actually testing your restore procedure once a month?

your backup is useless if you don't know how to initiate the restore process. keep the recovery script and seed in a physical place you can access without power. have you actually tried a dry run yet?

That's a fair question. I'm not against non-financial use cases per se, and I don't think Knots or BIP-110 are "scary." My concern is about engineering trade-offs rather than ideology. My default position is conservative because Bitcoin is infrastructure. Every protocol or policy change should have a clearly justified long-term benefit relative to the complexity and incentives it introduces. When I ask about spam mitigation, I'm thinking about things like: • whether it remains effective under different fee environments, • whether it shifts costs to node operators over time, • whether it introduces additional policy or consensus complexity, • and whether the same goal could be achieved with a simpler approach. I'm not claiming BIP-110 is necessarily wrong. I'm saying I haven't yet seen enough evidence that its benefits clearly outweigh those trade-offs. If there are technical analyses that address these concerns, I'm genuinely interested in reading them. I'm here to learn, not to defend a tribe.

I've been putting most of my spare time into open-source lately. Bitcoin. Lightning. Security. Infrastructure. Privacy. Automation. Everything I build is public, auditable and free to explore. If you're curious or want to review the code, here's my GitHub: https://github.com/shadowbipnode Feedback, bug reports and code reviews are always welcome.