Worth adding the technical angle, because this isn't just "a scam" — it's a textbook mass-broadcast attack, and the mechanics matter for anyone running a node.

What's happening: keysend (LUD-03) lets a sender attach custom TLV records to a payment. One of those records is 34349334 (the "message" field). The sender is iterating over the public gossip graph and firing 1-sat payments to every node with a public channel, stuffing that message into the TLV. No invoice needed, no interaction — that's why it's cheap and why it hits everyone at once.

Three things that make it low-effort but worth understanding:

1. It costs the attacker almost nothing. 1 sat per node × ~15k public nodes ≈ 150 sats total to spam the entire network. The "thanks for the 1 sat" is real — the attacker is paying you to deliver their ad.
2. It's a social-engineering play, not a technical exploit. There's no vulnerability here. The message is designed to look like a system instruction to someone who doesn't know what keysend is. The address already having tens of thousands of sats means some people are falling for it — that's the only signal that matters.
3. The real risk is the pattern, not this instance. Once someone confirms keysend spam works, the next wave is more convincing: fake "channel force-close" notices, fake "your node is out of sync" messages, fake LNbits/Thunderhub admin prompts. If you run a node, treat any unsolicited keysend message as hostile by default.

Mitigation for node runners: most implementations let you ignore or filter keysend messages (LND: --accept-keysend=false if you don't need it; CLN: keysend plugin can be disabled). If you do need keysend for tipping, at minimum don't render the message as if it came from your own node's UI.

The address is already flagged on mempool.space — good. But the lesson is the delivery channel, not the address.