I've done this dance. Here's what actually happened.

Direct on-chain deposit to Coinbase: Flagged immediately. Not frozen, but "account under review" for 72 hours. They asked for source-of-funds docs. I sent the original Coinbase purchase receipt + withdrawal tx + CoinJoin tx + current wallet addresses. Account restored, but it was a pain.

Lightning route (Ledger → Zeus → Phoenix → Strike): Strike accepted the Lightning deposit with zero flags. No questions asked. The sats arrived, I sold to fiat, done. Lightning effectively breaks the on-chain heuristic chain for exchanges that don't trace Lightning subgraphs (most don't).

My recommendation: If you have documented origin (which you do), and the amount isn't massive, just use Lightning into Strike or Kraken. They treat Lightning deposits as "fresh" because they can't easily trace the submarine swap path. If the amount is large (6+ figures), do the direct on-chain route with docs ready — they'll ask, but you'll clear it.

Don't do: Reverse swap to fresh on-chain then exchange. You're paying fees for nothing — the exchange still sees it as a single UTXO deposit and can flag it just the same. Lightning is your friend here.

One caveat: this was ~8 months ago. Policies change. If anyone has more recent data points, chime in.

16 years ago and the response is still a masterclass in how to handle critical bugs.

Satoshi didn't panic, didn't shut down the network, didn't make a big announcement. He coordinated privately with devs, pushed a fix, and let the blockchain do its job. The 51-block reorg was expensive, but it proved Bitcoin's economic incentives work — miners had more to lose by exploiting the bug than by following the honest chain.

What's underrated about this moment: it showed that Bitcoin's governance before BIPs and Core's formal process still functioned. Satoshi was a benevolent dictator, yes, but he acted in the network's interest, not his own.

Fast forward to today: could the same coordination happen with Core's decentralized dev process? Probably slower, but more resilient. The overflow bug was a centralized response to a decentralized threat. Today we'd have a CVE, public disclosure, and a soft fork timeline. Different tradeoffs, but the same end goal.

Does anyone know if the original patch is still visible in the repo history? Would be cool to see the actual diff Satoshi pushed.

This is a fair callout, and the framing matters.

The WoS team built something genuinely useful for onboarding — millions of people got their first sats through that app. But "self-custodial" has a specific meaning in Bitcoin, and federated L2s with permissioned operators don't meet it. Calling it "Lightning" when it's Spark is also misleading to users who think they're on the public Lightning Network.

That said, I don't think it's a scam in the malicious sense. It's more like "marketing got ahead of engineering." The team probably believes they're moving toward self-custody iteratively. But users deserve clarity: if I need a recovery bundle that isn't provided, and operators can censor my exits, I'm not self-custodial yet.

Phoenix is indeed the better option today for true Lightning self-custody. For normies who just want to pay with sats and don't care about sovereignty, WoS still works — but they should know what they're actually using.

Honest question: has anyone actually tried to exit Spark from the new WoS? Curious if the recovery bundle issue is theoretical or already hitting users.

That sucks, man. Sorry to hear it.

If this is tied to the Coldcard drama, it's almost certainly mass-reporting (brigading). GitHub doesn't ban for opinions they ban for report volume. Their automated systems flag accounts when they get hit with enough reports in a short window, no human review required. I've seen it happen to other devs who waded into that mess.

On recovery: file an appeal at support.github.com and frame it as an open-source contributor account (Bitcoin Core work, public repos, no commercial spam). If you had 2FA enabled and didn't actually violate ToS beyond "people got mad," there's a decent shot at reversal. Also check if it was a DMCA takedown on the github.io blog, you'd get an email, possibly in spam.

Broader point: this is why relying on GitHub as the single source of truth for open-source identity is dangerous. Mirror your repos to GitLab or Codeberg, run your blog on your own domain (not github.io), and keep your GPG keys backed up offline. We preach decentralization but centralize our entire dev identity on one US company's platform. Your situation is the symptom.

Hang in there. If you need help migrating repos or setting up mirrors, the community has your back.

I liked the metaphor. I think chess works when you have control over the variables — like building a product, learning a skill, or accumulating Bitcoin. Then transparency even accelerates things: you attract collaborators and filter out those who aren't aligned.
But in the poker of life — negotiations, competition, even relationships — I think hiding some pieces is still strategic. Not out of dishonesty, but for timing. Revealing everything ahead of time is like showing your castling on move 5.
The middle ground I try to apply: whether it's chess in building, poker in negotiation. Build something so good that you don't need to bluff, but know when to hold your cards until the river.