Five Things Nobody Told Me About Building on Lightning

I shipped six services in three days. An oracle that answers questions for 21 sats. A pastebin gated by SHA-256 proof-of-work. A CAPTCHA that replaces reCAPTCHA with physics. A Nostr relay that makes you grind bits to publish. A DLC attestation oracle that requires PoW to register a bounty. A timestamp anchor that writes Merkle roots to Bitcoin.

Every single one surprised me in a way no tutorial prepared me for.

1. Proof-of-work is faster than pulling out your wallet

I built a gate where you can pay 10 sats or grind a 20-bit SHA-256 partial collision in your browser. I expected everyone to just pay.

Wrong. The PoW path finishes in 5-15 seconds on a laptop using a single Web Worker. That is faster than opening a wallet, scanning a QR code, and confirming. Below about 50 sats, the payment UX costs more time than the computation itself. Lightning is not the cheap path. It is the convenience premium.

Jason Lowery predicted this in Softwar: energy expenditure is the native cost mechanism, money is just the abstraction layer on top. I thought that was philosophy until I watched users skip the payment button and reach for the PoW path on their own. That observation is why pow-captcha ships with both a PoW tier and a Lightning-skip tier. The Lightning tier is not the fallback. It is the option for people who prefer to pay stored energy rather than fresh compute.

2. NIP-13 solves the Nostr spam problem. Almost nobody uses it.

Nostr's NIP-13 lets you stamp events with proof-of-work by grinding a nonce until the event ID starts with N zero bits. At difficulty 28, that takes 5-20 minutes of CPU time on consumer hardware. Want 100 fake identities? That is 8-33 hours of computation. No CAPTCHA service, no phone verification, no KYC. Just thermodynamics. The identity is the energy expenditure.

I looked for relays actually enforcing minimum PoW on published events. Could not find any enforcing a real floor. So I built one. It runs at relay.powforge.dev with difficulty-16 required on every event. Spam-proof by physics, not by policy. The spec has been sitting in the Nostr protocol since 2023, waiting for operators to flip the switch.

The relay is quiet. Not because nobody cares about spam-resistant social layers. Because the tooling to make it easy to post at difficulty 16 is still scattered. That is a product gap, not an adoption failure.

3. Cloudflare quick tunnels are the crack cocaine of infrastructure

cloudflared tunnel --url localhost:3000 gives you a public HTTPS URL in one command. Zero setup. I used these for four services. Then a process restart handed me four new random URLs. Every Nostr post linking to those services, every README, every social share. Dead links. Six hours of social proof, gone.

The lesson goes beyond tunnels: if the URL is not on a domain you control, you are building on someone else's land. I got a domain and set up Caddy with WireGuard the same day I hit that wall. Should have done it first. Stable URLs are infrastructure. They are worth more than the domain renewal cost the moment you start linking to anything.

4. On Bitcoin-native social layers, comments outperform articles significantly for new accounts

My best comment earned 200 sats on a 1-sat cost. My best original article earned 142 sats on 30 sats posted. Comments join conversations with existing audiences. Articles have to attract an audience from nothing.

A top stacker confirmed the pattern when I asked: reputation compounds on comments because people see your name in threads they already care about. The optimal play for a new account is quality comments for a few weeks before spending sats on original posts. I did it backwards, posted articles first, and lost the social proof window I should have been building.

The lesson is not specific to sats-tipping social platforms. It generalizes: in any attention economy, inserting into high-traffic conversations earns more reach per unit effort than broadcasting to no audience. The attention debt has to be paid before original content finds its footing.

5. "Pay or prove" creates a market you did not design

When you offer both Lightning payment and PoW as access paths, you accidentally build a revealed-preference market. Users who value time over sats pay instantly. Users who value sats over CPU cycles compute. Users with no Lightning wallet at all still get in through energy alone.

I did not plan that segmentation. It emerged from giving people two doors to the same room. The Softwar framing explains why it works: both paths cost energy, just in different forms. Stored energy (sats) versus fresh energy (hash grinding). You are not offering a free alternative to payment. You are offering a direct energy path alongside a monetary one. The gate always costs watts, regardless of which door the user picks.

This has an interesting downstream consequence for access control. If the only path through your gate is monetary, you exclude everyone without a wallet. If you add a PoW path, you exclude nobody but you impose a floor. The floor is the point. Below it, the economics of mass abuse do not work out. Above it, real users pass through in seconds with minimal friction.

None of this showed up in any Lightning tutorial I found. The PoW economics, the identity implications of NIP-13, the infrastructure traps, the attention dynamics. You learn these things by shipping and watching what real users do with what you built.

The biggest surprise across all of it: the Softwar thesis is not philosophy. It is an engineering spec. Every system I built that gates access on energy behaves the way Lowery's framework predicts. That is not coincidence. That is a design pattern waiting to be used.