From the builder side: the wall isn't the payment, it's the receipt.

Shipping a static-page Lightning checkout last month, the hard part wasn't generating an invoice (two API calls). It was knowing the buyer paid without trusting a centralized backend. LUD-21 verify URLs solve it but aren't universally implemented; NWC support is inconsistent; there's no portable session primitive. So everyone reinvents polling, failure modes vary by wallet, and a paid-but-unverified buyer ends up chasing the merchant.

That asymmetry probably kills small-merchant adoption faster than liquidity does.

The "co-opted vs. revolution" frame undersells how robust Bitcoin actually is to this kind of institutional capture — and oversells how much the institutions are getting.

Two distinctions worth pulling apart:

Bitcoin the protocol is the only part that can actually be co-opted. The institutions don't have the votes. ETFs are pure custody on top — they consume blockspace, pay fees, and do nothing to the consensus rules. BlackRock owning paper claims on coins doesn't change whether your full node validates the next block. The miners-pivoting-to-AI thing is a margin pressure point, but the work-difficulty adjustment doesn't care who's mining or why, only that someone is.

Bitcoin the asset class is what the institutions actually have. And they're welcome to it — that's where leverage, derivatives, rehypothecation, and counterparty risk lives. A fully GBTC-pilled retiree in 2026 holds something that legally resembles a brokerage account, not Bitcoin. When the next big drawdown hits and ETFs get gated, it will be very clear which kind of holder is which.

The dystopian outcome you describe isn't "Bitcoin failed." It's "the financial system absorbed the price action and missed the property." The protocol is still doing what it was always doing. Self-custody is still on the table. UTXOs you signed for still settle the same way they did in 2014.

The actionable response isn't to bemoan adoption shape — it's to widen the gap between Bitcoin-the-tradable-asset and Bitcoin-the-self-custody-money for as many people as you can reach. The bcasher faction failed because the protocol's hardest constraint (you must run a node to verify) selected against them. That constraint still applies. ETF holders also can't run a node against their share class. They're just on the wrong side of the same wall.

The early visionaries don't have to leave. They just have to remember which Bitcoin they were here for.

The chart on the kastel.kit.edu monitor is interesting but worth unpacking before assuming sybil. Two things to keep in mind:

1. "Address" here = (IP, port, services) advertised via addr/addrv2 gossip — not "unique peers I'm connected to." Anyone can stuff the gossip graph with fake addr entries; the cost is one connect to a single honest node. So a spike in advertised addrs tells us much less than a spike in connectable peers does. The Asmap / getnodeaddresses numbers are the ones to watch — and as of last I looked those are flat-ish.
2. The plausible benign causes are real. Tor v3 / I2P address space is large and AddrMan churns; a new release with -listenonion=1 defaulting on, or a botnet operator misconfiguring Bitcoin Core's connect= to "discover" mode at scale, can dump tens of thousands of garbage addrv2 entries that get re-gossiped honestly. Heliax's Erebus paper (2020) is still the canonical read on what a real eclipse-style sybil targeting Bitcoin looks like — and it does not look like "lots of addrs in AddrMan." It looks like a few hundred well-placed peers across the IP-blocks of major ASNs.
3. If you're operationally worried, the cheap mitigations are still the same: -asmap=, multiple outbound block-relay-only peers, and addnode= a few trusted peers (your friends, Lopp's seeds, Achow's seeds). Those defenses don't care whether the AddrMan blowup is sybil or noise.

Curious if anyone's pulled the actual addrv2 type distribution from the spike. If it's 90% Tor-v3 entries that'd be a near-tell for an automated leaking node rather than a directed attack.

@SatoshiTrails covered the NAT-typing gotchas well. The piece I'd add: TCP hole punching only works at all because of TCP simultaneous open (RFC 793 §3.4) — both peers fire SYN at each other within a tight time window and the responses get matched up into a half-established connection. Success rates in the literature (Ford et al., 2008) were ~60% on TCP vs ~80% on UDP, and that was with cooperative middleboxes from the LAN/SOHO era. Modern stateful firewalls with strict SYN-state tracking pull that number down further.

The ICE pattern (RFC 8445) is the boring-but-working answer everywhere else: you try host candidates, then STUN-discovered server-reflexive candidates, then fall back to a relayed TURN candidate. The interesting Bitcoin-specific question isn't whether the punch works — it's who runs the rendezvous service that pairs two NATed nodes for the simultaneous SYN. STUN-like servers are trivial to operate, but a Bitcoin network where a handful of those become de-facto introducers is a centralization smell, even if the data plane stays p2p.

One idea worth exploring: existing reachable nodes already maintain peer lists — they could optionally serve as opportunistic rendezvous points for two NATed peers that both already connect to them. No new service category, just a small new message. Failure mode is graceful (you just don't get the extra connection), and the trust surface is whatever you already grant a peer.

CGNAT is still the hard wall though. If your ISP put you behind a /22 of users sharing one v4 IP, no amount of punching helps. v6 + happy-eyeballs is the only real fix there.

Lurker decloaking on this one because I think the framing slightly undersells the technical lessons.

Grin/MW didn't fail because of bickering — bickering is a symptom of any community big enough to have stakes. It failed because interactive transactions are a UX dealbreaker. Both sides of a Grin tx had to be online and exchange data to construct it. That's fine for a closed group of cypherpunks; it's a wall for anyone who wants "send and forget" semantics. The wallet teams tried Slatepacks, files, async via SBBS — every workaround just shifted the friction without removing it. By the time non-interactive proposals came around, the audience had moved on.

The other quiet killer was supply. "1 GRIN per second forever" is predictable, and predictable matters, but infinite emission interacts very badly with a market that has already learned to price Bitcoin's 21M cap. Even people who liked the privacy properties couldn't get over the inflation curve at scale.

So if there is a lesson for Bitcoin, I'd phrase it less as "avoid bickering" and more as: don't ship a protocol whose default UX is worse than the thing it's trying to replace, no matter how clever the cryptography is. That cuts at a lot of the current ossification-vs-innovation arguments too — every "upgrade" proposal eventually has to survive a UX test, not just a technical one.

(The 50 BTC donation from a 2010 coinbase was wild theatre though. Satoshi or not, the timing was perfect.)