Rusty Russell

Rusty Russell (Medium) Review Guide: Everything You Need to Know + FAQ

Ever wondered if Rusty Russell’s Medium is actually worth your time—or where to start so you don’t get lost in Lightning jargon? If you work with Bitcoin Lightning, you’ve probably seen his posts shared around and thought, “This looks smart, but do I need all of it right now?” Good question.

Why this can feel harder than it should

Lightning moves fast. Rusty writes with the precision of someone who lives inside the protocol, which is both a gift and a challenge. Here’s what trips most people up:

• Signal vs. noise: BOLT updates, PRs, and “coming soon” features can blur together. Which ideas actually matter for your node, wallet, or app?
• Translating ideas into action: It’s one thing to read about fees, liquidity, and pathfinding. It’s another to know what to change on your setup tomorrow.
• Time sink risk: Great writing can still cost you hours if you don’t know where to start or when to stop.
• Varied maturity: Some topics—like Offers (aka BOLT12)—are still evolving. Wallet and implementation support can differ, so you need a reality check before flipping switches.

To put the stakes in perspective, consider real-world reliability: River reported handling millions of Lightning payments with a ~99.7% success rate in 2022–2023 conditions—excellent, but the last few tenths of a percent often come down to the exact fee, liquidity, and routing policies you choose. That’s exactly the territory Rusty explores.

What you’ll get from this guide

I’ve been reading Rusty’s work for years and using it to make practical decisions. My promise is simple:

• Clarity on what Rusty covers and why it matters right now.
• A reading plan by skill level so you don’t waste time.
• Concrete next steps to turn insights into safe experiments on your setup.
• Fact-check pointers so you avoid cargo-culting tips that don’t match your stack.

Lightning rewards people who test ideas small, measure honestly, and keep a quick rollback handy.

Why this review is worth your attention

I spend most days testing crypto tools, skimming BOLT discussions, and tracking how Lightning features behave across clients. I’ve seen Rusty’s posts help in the messy middle—where design meets production. Expect friendly, no-fluff guidance and examples tied to real outcomes like payment reliability, liquidity costs, and privacy trade-offs.

How this guide works

We’ll keep it practical and fast:

• Start with who Rusty is and why his Medium matters in Lightning.
• Map the core themes he writes about and who each one helps.
• Pick your best starting posts based on your level and goals.
• Use a lightweight plan to test ideas safely and keep learning without burning hours.
• Finish with a straight-up FAQ that answers the usual questions people ask about his work and Lightning in general.

If you want fewer tabs and better decisions, you’re in the right place. Ready to see why Rusty’s posts carry so much weight for builders, node runners, and curious readers? Let’s start with who he is and what makes his Medium worth following.

Rusty Russell at a glance: why his Medium matters in Bitcoin Lightning

When Lightning gets noisy, I look for one thing: signal. Rusty Russell’s Medium is where the signal lives—clean reasoning, hard numbers when they matter, and real trade-offs you can use the same day.

“Great Lightning engineering is less about magic and more about clear trade-offs.”

He doesn’t just describe features; he explains why they exist, when to use them, and what can go wrong. If you’re building, running a node, or simply curious about where the protocol is headed, his posts cut through the fog.

Who is Rusty Russell?

Rusty is a veteran Lightning developer and long-time contributor to the BOLT specifications that define how the Lightning Network works. He’s known for straight talk on protocol design—what’s fast, what’s safe, and where you’ll pay a hidden cost. That perspective shows up in his writing: you’ll get the “why” behind decisions, not just a list of flags.

On any given post you might see him unpack:

• Invoice design and “Offers” (BOLT12): Why a single, reusable “offer” string can replace one-use invoices, how wallets request fresh invoices, and how privacy is preserved by default.
• Onion messaging: How to communicate without a payment attached—useful for things like fetching an invoice or coordinating multi-step flows across the network.
• Reliability vs. cost in routing: Where fees, liquidity placement, and path choices collide with real-world constraints. He often references community research (for example, work like Pickhardt/Richter on cost-reliable flows: arXiv:2107.05322) and shows what actually helps on mainnet.

He’s also one of the clearest voices on failure modes—force-closes, stuck HTLCs, probing—and why “it works on my node” isn’t the same as production ready. If you’ve ever been burned by a rare edge case, his tone will feel like a lifeline.

What is Core Lightning (aka c-lightning)?

Core Lightning (formerly c-lightning) is one of the major Lightning implementations. It’s written in C, designed to be lean and modular, and driven by a plugin-first mindset. Think JSON-RPC control, composable plugins, and small daemons that each do one job well.

Why that matters for his Medium: Rusty’s posts often connect protocol ideas to actual engineering decisions. You’ll see things like:

• From spec to switch: He’ll outline a design proposal in the BOLT specs, show how Core Lightning exposes it behind an experimental flag or plugin interface, and explain how to test it safely.
• Operational realism: Instead of “we should,” you’ll get “we tried this setting on CLN, here’s how it affected routing success and liquidity churn.”
• Modularity as a feature: Expect tips that lean on CLN’s plugin ecosystem—fee policies, liquidity automation, or probing protections you can turn on, measure, and turn off without drama.

You don’t have to run Core Lightning to benefit, but if you do, his write-ups feel like a guided upgrade path for your node—feature by feature, risk by risk.

What you’ll typically find on his Medium

Rusty’s posts are a steady mix of protocol insight and get-it-done advice. Common themes include:

• Protocol insights and BOLT updates: Clear explanations of proposals like BOLT12 Offers or new onion message flows, with the trade-offs spelled out so you’re not guessing.
• Fees and liquidity as a policy: Examples of setting a goal (throughput, margin, reliability), measuring results, and nudging fees/liquidity rather than whipsawing settings.
• Privacy by design: Why static “offers” can protect users, how route blinding and onion messages reduce metadata leaks, and what a realistic threat model looks like for merchants and routers.
• Pathfinding and reliability: What actually improves payment success—smarter path selection, liquidity placement, and cautious retries—backed by both engineering notes and community research.
• Splicing and operational upgrades: How to increase or reshape channel capacity without going offline, and what to watch out for so fees don’t eat your margins during busy mempool periods.
• Edge cases and failure modes: Lessons from force-closes, reorgs, or probing attacks, with practical guardrails you can implement right away.

Real-world sample you’ll see him champion: publish a single BOLT12 “offer” on your website or store. A wallet can request fresh invoices from that offer via onion messages, so you get reusable QR codes, better privacy, and less invoice management overhead. It’s the kind of improvement that feels small until you run it in production.

If you’ve ever opened one of his posts and wondered, “Is this the kind of content that fits my level and goals?”—good question. Want the no-nonsense answer on topics, style, and who gets the most value? Keep reading next; I’ll map it exactly so you pick the right pieces and skip the rest.

What Rusty actually writes about: topics, style, and who it’s for

I read Rusty when I want clarity on Lightning that I can actually use, not just read and forget. He writes for people who want to press real buttons and ship real code. Here’s how to get the signal without getting lost.

Core themes you’ll see

Expect hands-on topics that shape how you operate a node, design a wallet, or reason about routing. A few big buckets keep showing up:

• Deep protocol explanations: He breaks down the why behind HTLCs, gossip, and failure modes so you don’t cargo-cult your config. It’s the difference between “it works” and “I know why it works.”
• Channel management and liquidity strategy: Practical takes on where to place liquidity, when to rebalance, and how to think in policies, not hope. This lines up with research like Pickhardt & Richter’s liquidity-aware routing (arXiv:2107.05322) which shows why fees and capacity shape reliability.
• Offers (BOLT12): Reusable, privacy-friendly invoices that remove the “invoice-per-payment” hassle. Rusty explains how Offers handle payer-initiated flows and refunds without leaking static identifiers. For the spec-minded, check the BOLT discussion on Offers in the BOLTs repo.
• Onion messaging: How to send arbitrary, end-to-end encrypted messages across the network—no payment attached. He shows where this unlocks things like offers negotiation and feature discovery without gossip bloat. It’s all about keeping data minimal and private.
• Pathfinding trade-offs: Why “cheapest path” isn’t always the best path, how to reason about success probability, and how to avoid routing thrash. If you’ve seen ACINQ’s analysis on reliability vs. cost (ACINQ blog: Path-Finding in Lightning), Rusty’s writing rhymes with that real-world pragmatism.
• Splicing: Opening/closing without downtime by adjusting channel capacity on-chain while keeping it live. He covers when splicing shines (e.g., topping up capacity mid-rush) and the gotchas around fee bumps and mempool churn.
• Real-world ops lessons: From probing and payment griefing to gossip sanity and watchtower assumptions. He’ll walk through “this failed in production, here’s what we learned.” Papers like “Flood & Loot” (arXiv:2006.08513) show the threat landscape; Rusty maps that to knobs you can actually turn.

What I appreciate most: he moves from concept to consequences. Not “feature X exists,” but “here’s how it will change your routing reliability, and here’s how an attacker might poke it.” That lens saves time and money.

“Complex systems reward curiosity and punish assumptions.”

Writing style and level

Rusty writes plainly, but he doesn’t sand down the edges. He assumes you’re happy to read a chart, look at a message flow, or try a flag yourself. It’s technical in the best way: you’ll see trade-offs, not slogans.

• No fluff, real context: He’ll show why a naive fee policy gets you probed to death or why a channel looks “healthy” until a specific HTLC shape hits it.
• Narrative + spec: He often pairs a story (what broke, why) with pointers to how the spec actually behaves. If you like to cross-check, keep the BOLTs open while you read.
• Assumes curiosity: Beginners can keep up if they’re willing to pause and Google a term or two. Developers and operators will feel right at home.

Think of it like reading a seasoned postmortem that turns into a playbook. You won’t get hand-holding, but you will get the map.

Who gets the most value

• Wallet and app builders: If you’re shipping LN features—Offers, keysend, async payments, onion messaging—Rusty’s posts help you design defaults that work on mainnet, not just a local test.
• Routing node operators: You’ll pick up on fee policy shape (base fee vs. proportional), how rebalancing actually affects success rates, and when a “cheap” channel becomes a liability. This aligns with liquidity-aware approaches discussed in research and operator forums—set goals, measure flow, adjust slowly.
• Merchants and payment processors: He explains reliability from the receiving side: invoice lifetimes, partial failures, and why some failures are normal and actionable rather than mysterious.
• Security and privacy tinkerers: If you care about what metadata leaks and where, his writing makes you rethink defaults around gossip exposure, probing resistance, and monitoring—grounded in how Lightning really routes packets.

Concrete example: suppose you’re debating whether to set a non-zero base fee. Community experiments and liquidity-aware routing research suggest that a low or zero base fee with a sane proportional rate often improves multi-hop success. Rusty explains why that happens in practice—path selection punishes unpredictable toll booths—and how to confirm it with your own metrics before flipping every channel at once.

Another: you want to add BOLT12 Offers for reusable invoices. He’ll outline the threat model (don’t leak static identifiers), the user experience win (no “send me a new invoice”), and the operational plan (test onion message reliability and wallet UX before production). That’s the missing link between “cool feature” and “this actually reduces support tickets.”

Curious which posts to start with for your skill level, so you learn fast without bouncing off the jargon? Up next, I’ll match Rusty’s best articles to four reader profiles—new to Lightning, running a node or business, building apps/tools, or focused on privacy. Which one sounds like you?

Best starting points: how to pick Rusty’s posts for your level

You don’t need to read everything on Rusty Russell’s Medium to get massive value. Pick your lane below, skim the right pieces, and you’ll move faster with fewer dead ends. As one line I keep taped above my desk says:

“Read for the why, test for the how.”

If you’re new to Lightning

Start with posts that explain how payments actually travel, what channels are, and why fees exist. This builds instincts, not just trivia—so when something fails in the wild, you know where to look.

• Routing and HTLCs, in plain English: Look for intros where Rusty breaks down HTLCs, time-locks, and multi-hop routing without assuming you’re a protocol lawyer. Use the search: HTLC, routing.
• Why fees exist (and why “free” breaks things): Find his fee rationale posts—how base_fee and proportional fee shape traffic and protect liquidity. Search: fees.
• Channel basics: The mental model: a channel is a shared wallet with rules. You’ll want posts that compare opens, rebalances, and closes with real-world examples. Search: channel.

Real sample: If a 50k sat payment fails, it’s usually not “Lightning is broken”—it’s path liquidity or fee policy on one hop. After reading Rusty’s routing primers, that error message becomes a clue, not a mystery.

Quick wins this week:

• Read one routing explainer + one fee explainer.
• Send 5–10 small payments through different routes and note the failures. Label each with a likely cause using your new mental model.

Confidence boost: River’s 2023 Lightning report showed ~98% payment success across millions of payments—most failures traced back to liquidity and fees, exactly the areas Rusty teaches you to reason about.

If you run a node or a business

You’re juggling reliability, cost, and privacy. Prioritize posts where Rusty talks fee policy as a feedback loop, liquidity planning like a budget, and the trade-offs you accept to hit your KPIs.

• Fee policy that learns: Look for pieces on base_fee = 0 vs small-but-nonzero, proportional fees that match typical payment sizes, and why “set and forget” fee schedules slowly rot. Search: fee policy.
• Liquidity as inventory management: Posts that treat channels like stock on shelves—where to place it, how often to rebalance, and when to close underperformers. Search: liquidity.
• Reliability playbook: Expect guidance on monitoring forwards, interpreting failure codes, and not overfitting to temporary network conditions.
• Privacy trade-offs: Rusty often lays out “if you want X, you give up Y.” That framing helps you choose sane defaults for invoices, probing resistance, and logging. Search: privacy.

Real sample: Many operators experimented with zero base_fee to attract micro-payments, then reintroduced a tiny base_fee after seeing spammy forwards without revenue. Rusty’s fee-writing gives you the language and logic to iterate without guesswork.

Operational checklist to try after reading:

• Pick one high-traffic channel and adjust proportional fee +/- 10% for a week; measure forwards and revenue per sat of liquidity.
• Set a monthly “close or fix” threshold for idle channels (no forwards, low capacity utilization).
• Turn off noisy logs you don’t actually use; turn on the metrics that correlate to your goals (success rate, revenue, avg route length).

If you build apps or protocol tools

Skip straight to the posts where Rusty explains how features hang together in the protocol, so you can ship things that actually work on mainnet and won’t corner you later.

• Offers (BOLT12): His write-ups on Offers clarify why static, reusable “offers” beat invoice copy-paste, how onion messages deliver them, and what fallback paths look like. Start here: BOLT12.
• Onion messaging: You’ll want the mechanics and gotchas—message size, retries, and UX expectations for asynchronous payments. Search: onion message.
• Plugin patterns: Rusty often shows how plugins extend Core Lightning safely. That mental model helps even if you’re targeting another stack. Search: plugin.
• Spec notes and trade-offs: Posts that read like “why the spec says this” are gold for avoiding edge-case footguns. Search: BOLT.

Real sample: Implementing BOLT12? Start with Rusty’s Offers overview, then prototype a flow where your app accepts an offer, requests an invoice via onion message, and falls back to a legacy BOLT11 if peers don’t support it. Ship the fallback first, gate Offers behind a flag.

Dev shortcuts:

• Keep feature flags for “Offers,” “onion messages,” and “splicing” so you can roll forward/back quickly.
• Write property tests for partial failures (one hop unreachable, invoice expired mid-flight, amount mismatches).
• Log feature support by peer on first contact; adapt UX (e.g., hide request-invoice if peer lacks onion messaging).

If you care about privacy and security

Lean into posts where Rusty talks threat models, probing, backups, and watchtower realities. You’ll learn what metadata leaks by default and which knobs actually reduce risk without bricking your UX.

• Payment probing and metadata: Look for analyses of how route attempts reveal liquidity hints and what settings blunt that without crushing success rates. Search: probing.
• Invoice and offer privacy: Posts on BOLT11 vs BOLT12 privacy give you a practical checklist—reuse-resistant invoices, blinded paths, and message-level hygiene.
• Backups and failure modes: Expect no-nonsense advice: test restores, understand when a “backup” is a liability, and how to avoid force-closing everything at once.
• Watchtowers and monitoring: Learn where watchtowers help, where they don’t, and how to pick heartbeat intervals and alerting that catch real risks.

Real sample: If you’re worried about invoice reuse leaking metadata, Rusty’s Offers posts show how a static offer can still request a fresh invoice per payment—good privacy without the copy-paste treadmill.

Hygiene to implement this weekend:

• Rotate and test your backups on a throwaway machine; time the full restore-to-forwarding path.
• Enable blinded paths where supported; validate your success rate after enabling.
• Set alerts for “stuck HTLCs > N minutes” and “channel balance skew > X%” to catch attacks that look like “just congestion.”

Feeling a spark and want to turn this reading into measurable wins? In the next section, I’ll hand you a lightweight workflow to go from post → small experiment → production change without anxiety. Want a one-page template that keeps you from over-tweaking and breaking things?

Turn reading into results: a simple plan to learn and build

You don’t need a 12-hour reading spree to get value from Rusty Russell’s Medium. You need a tight loop: read smart, validate fast, and ship tiny improvements. Here’s the plan I use to turn his ideas into working changes on real nodes and apps—without breaking production or chasing hype.

Read in layers

Skimming is a skill. So is knowing what to reread.

• Layer 1 — 90-second skim: Grab the core claim and the “why.” Highlight key nouns/verbs: Offers (BOLT12), splicing, onion messaging, fee policy, liquidity rebalance. Write down one question you want answered.
• Layer 2 — trade-offs pass: List 3 bullets: benefits, risks, dependencies. Example: “Zero base fee lowers friction for small payments; may attract micro-payments; risk of lower revenue unless ppm is tuned.”
• Layer 3 — experiment pick: Choose one small change you can test within a day. If it takes longer, the scope is too big.

“What gets measured gets managed.” — Peter Drucker

Tip: This layered read mirrors how good engineers absorb specs. It saves time and reduces the “I read 5 posts and changed nothing” paralysis.

Pair Medium posts with specs and docs

Think of Rusty’s posts as the story. The BOLTs and client docs are the exact map.

• Map the topic to a BOLT:

  • Invoices → BOLT 11
  • Gossip & channel updates → BOLT 7
  • Onion routing → BOLT 4
  • Offers (widely called BOLT12) → active spec work and implementation notes

• Cross-check your stack:

  • Core Lightning → docs.corelightning.org
  • LND → api.lightning.community
  • Eclair → acinq.github.io/eclair

• Create a quick “flags sheet” for each idea: feature name, relevant RPC/CLI flags, defaults, gotchas, and the exact version that supports it.

Why this matters: research suggests routing is a balance of reliability and price—see Pickhardt & Richter’s work on payment forwarding and reliability (arXiv:2107.05322). Specs + docs keep you honest about behavior and edge cases, so your experiments are grounded, not guessy.

Set up a small lab

A sandbox cuts fear. You can be bold where mistakes are cheap.

• Environment: Use signet or regtest for fast cycles. Tools like Polar spin up Core Lightning, LND, and Eclair topologies in minutes.
• Topology to start: Three nodes (A↔B↔C). A pays C through B. Give B mid-sized capacity; make B your “policy lab.”
• Core experiments to try:

  • Fee policy: set base fee to 0 and adjust ppm in small steps (e.g., 200 → 350 → 500). Track throughput and failures.
    CLN:lightning-cli setchannelfee<peer or scid> 0 350
    LND:lncli updatechanpolicy--base_fee_msat=0 --fee_rate=0.00035
  • Liquidity planning: push inbound/outbound, then send varied-size payments to see when failures spike. Use rebalancing tools or simple circular payments.
  • Onion messaging and Offers (where supported): create an offer, pay it, and watch logs for route selection and fallbacks.
  • Splicing (if available in your client): open with a small amount, splice in/out, verify channel usability during on-chain transitions.

• What to measure:

  • Success rate (count vs. attempts)
  • Median payment latency (ms)
  • Revenue (msat/day for forwarders)
  • Fail reasons (insufficient capacity, fee too high, timeout)

• How to measure fast:

  • Core Lightning:listforwards, listchannels, paystatus
  • LND:lncli fwdinghistory, lncli feereport, lncli getchaninfo
  • Ship stats to Prometheus/Grafana if you can. Even a CSV export into a quick spreadsheet beats guessing.

Real example you can run today: after reading a post about fee policy, set B’s base fee to 0 and ppm to 300. Fire 100 payments of different sizes from A to C. Compare:

• success rate before vs. after
• latency distribution (did small payments get faster?)
• earned fees per 100 payments

If the results look promising, move the same change to one production channel with low risk and monitor for 24–48 hours. No hero moves. Small wins, chained together.

Document your takeaways

Reading is fuel. Documentation is traction. Keep a one-page log per topic so insights compound instead of fading.

• Template (copy this):

  • Topic: e.g., “Fee policy — zero base fee + 300 ppm”
  • Source idea: link to the Rusty article + BOLT/implementation docs
  • Hypothesis: “Lower base fee should improve small-payment success without killing revenue”
  • Setup: topology, versions, exact flags
  • Metrics: success rate, latency, revenue, fail reasons
  • Result: short bullets with numbers and screenshots if possible
  • Decision: keep, tweak, or rollback
  • Next action: what you’ll try next, by when

• Cadence: one experiment per week beats five abandoned ideas. The habit is the moat.

I know the feeling: you finish a great article, nod along, and… life happens. This system keeps you shipping. As a bonus, if you operate a public node, these notes become your “operator’s manual” when things get weird—reorgs, channel closes, liquidity droughts, you name it.

One more nudge: many operators report that moving toward zero base fee with well-chosen ppm improves throughput for small payments, but the sweet spot depends on your topology and peers. There’s no universal setting—just a repeatable way to find yours.

So how do you make sure you’re not just copying someone else’s settings or taking any claim at face value? Up next, I’ll show you how to sanity-check advice (even Rusty’s), verify against specs, and know when a change is truly ready for production without guesswork.

Is Rusty unbiased? Accuracy, trade-offs, and how to fact-check

Rusty Russell writes from the trenches. That’s exactly why his posts are useful—and exactly why you should read them with a builder’s filter on. He has opinions, they’re informed, and they often reflect Core Lightning (c-lightning) priorities. That doesn’t make them biased in a bad way; it makes them anchored in real engineering. Your job is to figure out what holds across stacks, and what’s specific to your setup.

“In God we trust; all others must bring data.” — W. Edwards Deming

Perspective you should expect

Here’s the lens I keep in mind when I read:

• Spec-first thinking: He references BOLT behavior, edge cases, and why certain flags exist. Expect pragmatism and protocol rigor over buzzwords.
• Core Lightning flavor: CLN’s plugin-friendly, UNIX-style approach shows up in examples and suggested patterns. It’s a strength—but some defaults differ from LND, Eclair, or LDK.
• Feature advocacy with caveats: When he pushes concepts like Offers (BOLT12), onion messaging, or splicing, he’s speaking to capability and end-user benefit. Interop and rollout timing still vary by client.
• Trade-offs stated plainly: Privacy vs. reliability, fees vs. flow, safety vs. UX—he rarely paints in absolutes. Read the “it depends” parts twice.

Emotionally, this is the right mindset: trust the experience, then verify fit for your world. Lightning is a live network—small mismatches can cost real money.

How to verify claims

If a post nudges you toward a change, treat it like a mini research task. Here’s a fast, repeatable workflow that’s saved me time and coins:

• Map statements to specs: Find the relevant BOLT. The canonical repo lives here: github.com/lightning/bolts. Look for feature flags like option_anchors, option_static_remotekey, option_wumbo, and discussions around BOLT12.
• Compare client docs: Check your stack’s behavior and defaults:

  • Core Lightning (CLN)
  • LND
  • Eclair
  • LDK

• Read the room: Scan active threads on lightning-dev and BOLTs PRs/issues to see current consensus or pushback.
• Reproduce in a sandbox: Spin up a regtest or use a local lab (Polar, signet, or two small cloud nodes). Try the config exactly as suggested. Measure:

• Payment success rate and median/95th latency
• Forwarding success rate and fee revenue (ppm + absolute)
• HTLCs in-flight, timeouts, and failure reasons
• Channel balance distribution before/after
• Mempool sensitivity (fee spikes, CPFP/anchor behavior)

• Cross-check with research: When guidance touches routing, liquidity, or privacy, I like to pair it with:

  • Pickhardt & Richter: Optimally Reliable and Cheap Payment Flows on the Lightning Network (routing/liquidity math)
  • Harris & Zohar: Flood & Loot (security/economic stress on channels)

• Document your results: One page, no fluff: claim, test scope, metrics, decision. Future-you will thank you.

Real-world example 1: Offers (BOLT12)
I enabled BOLT12 on a CLN test node to replace invoices for repeat payments and donations. Interop was the sticking point: CLN handled Offers smoothly; other nodes varied by version and feature flags. So I added a fallback—standard invoices for peers that couldn’t negotiate Offers—and tracked how often the fallback triggered. Result: users got a better UX where supported, without breaking payments where it wasn’t.

Real-world example 2: Fee policy claims
There’s a recurring idea that slightly higher base fees on scarce, high-demand channels can improve revenue without killing flow. I set a canary subset of channels to a new base+ppm combo, kept the rest as control, and measured seven days:

• Forward revenue (ppm and total sats)
• Number of forwards and success rate
• Balance oscillation and stuck liquidity

The data made the decision obvious—and reversible. Some channels loved the change; others starved. I promoted the winners and rolled back the losers instantly.

Interop sanity checks worth doing before you ship

• Send/receive between at least two different implementations.
• Test forced closes during mempool congestion; verify CPFP/anchor behavior aligns with your fee-bumping plan.
• Check that your logging actually captures the failure reasons you care about (unknown next peer, temporary channel failure, insufficient fee, etc.).
• Probe privacy exposure: what does your node leak via invoices, probing, or gossip? If you’re adding onion messaging, confirm routes and fallbacks.

Signs you’re ready for production changes

• You can explain the trade-off in one sentence. If you can’t, you’re not ready.
• Sandbox results are stable across mempool states. Low-fee and high-fee periods both tested.
• Interop checks pass against your top peer types (LND, CLN, Eclair, LDK).
• Metrics are wired and alerting. You know your baseline and acceptable regressions for success rate, latency, and revenue.
• Rollback is one command or one config flip. No heroics required under pressure.
• Canary first. Roll out to 5–10% of channels or one node. Wait a full rebalancing cycle before scaling.
• Backups verified. Static channel backups and emergency close procedures tested. No excuses here.

Red flags: You’re copying a config wholesale; you haven’t read the corresponding BOLT; your peers run different versions; you can’t measure the outcome; or you’re planning changes during a mempool spike. That’s how good ideas turn into expensive lessons.

If this sounds like work, it is—but it’s also how you turn smart posts into your edge. Want the short list of the most common mistakes people still make with Lightning—and how to skip them? That’s exactly what I’m tackling next.

Key lessons and common mistakes people make with Lightning

Fees and liquidity are policy, not magic

“Hope is not a strategy.” It’s definitely not a routing policy. Fees and liquidity should express your goals, not your wishes.

• Pick a goal for each channel. Do you want volume, profit, or reliability? Price differently for each. For example:

  • Volume-first: low base fee (0–1 sat) and modest ppm (20–100) to attract flow.
  • Profit-first: base fee low, but raise ppm when outbound capacity is scarce.
  • Reliability-first: keep fees stable and conservative; avoid frequent changes.

• Adjust slowly, measure weekly. Change fees in small steps (10–20%), then wait. Whipsawing your policy confuses peers and hurts pathfinding.
• Price scarcity, not noise. As a channel’s outbound falls (say below 30–40%), step ppm up. When it refills, step down. That’s policy, not guessing.
• Watch the right metrics:

  • Forward success rate (settled vs. attempted forwards).
  • Revenue per channel per sat-month (are sats actually working?).
  • Time-to-settle and stuck HTLCs (quality of service).

• Mind your base fee. Many operators minimize base fee and price via ppm so multi-part payments can stitch through you more often. This lines up with liquidity-aware routing research (see Pickhardt & Richter, 2021).

Quick reality check: If you route 1,000,000 sats/day at 50 ppm, that’s ~50 sats/day from that channel. Volume matters. Use policy to earn consistently instead of chasing spikes.

Privacy is a set of choices

Lightning can be very private—or very not—depending on your settings and habits. Each choice leaks or shields metadata.

• Invoices leak context. Descriptions and static QR codes can correlate payments. Rotate invoices and avoid human-readable clues that tie back to users or orders.
• Receiver privacy: blinded paths and Offers. Features like route blinding and BOLT 12 Offers help hide your receiving node’s topology. Adoption is growing, but wallet support varies—use them where both ends support it.
• Transport matters. Exposing a clearnet IP tells the world where your node lives. Running an onion service reduces that surface.
• Probing is real. Attackers can infer liquidity with clever retries. Use payment secrets (standard in modern invoices), reasonable min-htlc, and avoid verbose failure messages if your stack lets you tune them.
• Operational opsec: separate logging for payments vs. user data, and scrub request logs. Your own tools can deanonymize you faster than any adversary.

Field tip: If you accept donations, prefer a static Offer with a blinded path over a permanent invoice image. You reduce linkability while making it easier for supporters to pay you repeatedly.

Don’t ignore edge cases

Lightning’s happy path is smooth—until it isn’t. Resilience comes from rehearsing the bad days.

• Backups you can actually restore.

  • Keep offsite copies of your node keys and channel state. Encrypt them. Test a restore every quarter on a throwaway machine.
  • If your implementation supports static channel backups, store them in multiple places; they’re a last resort to claim funds if your live state is gone.

• Channel closes under stress.

  • Cooperative close is cheap; force close is not—especially in fee spikes. Keep an on-chain buffer for CPFP and emergencies.
  • Know your to_self_delay and what that means for when you can spend after a force close.

• Reorgs and timeouts.

  • Rare, but they happen. Make sure your node tracks chain state and doesn’t cut it close on HTLC expiries.
  • If you can’t stay online, consider a watchtower setup so someone else can punish a stale state broadcast.

• Run a monthly “chaos hour.” On a sandbox:

  • Kill the node and restore from backup.
  • Simulate a force close and confirm you can sweep outputs.
  • Push mempool fees high and see if your alerts and CPFP flow trigger.

Reminder: If you haven’t tested it, it will test you. Edge cases are where most losses and panics happen.

Features versus production reality

New Lightning features feel like a superpower—until they brick a Saturday night checkout. Be deliberate.

• Check network support. A feature is only useful if your peers and users can speak it. Offers, splicing, route blinding, zero-conf channels—all great in the right context, not universal yet.
• Roll out with canaries. Enable on one or two channels first. Watch failure codes, success rate, median payment latency, and user complaints. If it looks clean for a week, scale up.
• Always have a rollback plan. Know exactly which flags to flip back, which plugins to disable, and how to revert fee policies without thrashing the graph.
• Prefer boring that works. Stable throughput with clear logs beats flashy toggles that add unknowns. Consistency attracts good peers.

“Lightning rewards operators who think in policies, not hunches.”

Want quick answers like whether this advice applies across implementations, how technical Rusty’s posts get, or where to start if you’re new? I tackle those next in the FAQ—what’s the one thing you want cleared up first?

FAQ: quick answers people ask about Rusty Russell’s Medium and Lightning

Is Rusty Russell’s Medium good for beginners?

Yes—if you’re willing to learn a few basics as you go. His writing is clear, and he explains why things exist, not just how to run a command. If you’re new, start with posts that describe how payments move across channels, what routing means, and what HTLCs do. Read one concept, then pause and sketch a payment path or try a simple test on a regtest node—you’ll internalize it faster.

Real-world tip: readers who pair his explanations with a small sandbox (even 2–3 nodes) usually “get” fees and liquidity within a day. That’s consistent with what I’ve seen running tiny lab setups: the first “aha” moment is seeing how a slightly higher fee on one channel can redirect routes in minutes.

What’s the difference between c-lightning and Core Lightning?

They’re the same project. “c-lightning” was the original name; “Core Lightning” (CLN) is the rebrand. You’ll see both names used in older and newer posts. Rusty has been a long-time contributor to this implementation and the BOLT specs that define Lightning’s rules.

Which topic should I read first?

If you’re not sure where to begin, use this path:

• Routing and channels: understand multi-hop payments, channel balance, and why liquidity placement affects success rates.
• Fee thinking: base fee vs ppm, how to set a goal, and how to adjust slowly while watching your flows.
• Offers (BOLT12) and onion messaging: how static, reusable “offers” improve privacy and UX compared to one-time invoices.
• Liquidity strategy: when to open, where to rebalance, and how to align with your traffic.

That order works because it moves from “how Lightning moves money” to “how to influence that movement” to “how to ship better UX.”

How technical are his articles?

Technical, but grounded. Expect specifics, trade-offs, and reasoning. He’ll explain why a feature matters, what risks it addresses, and where it can break. If you’re comfortable with clear examples, occasional pseudo-code, and protocol terms like HTLCs, onion routing, and splicing, you’ll feel right at home.

Practical example: when he talks about payment probing, you won’t just get “probing exists”—you’ll get why probing can leak metadata and what design choices (like Offers and better pathfinding) do to reduce that leakage.

Can I apply his advice on other Lightning implementations?

Often yes, but verify. The principles (fees as policy, liquidity placement, privacy trade-offs) carry across CLN, LND, and Eclair. What differs are flags, defaults, and edge behaviors.

• CLN: flexible plugins and tools to tweak fee policies and liquidity workflows.
• LND: similar fee knobs (base_fee_msat, fee_rate) and channel management, but check invoice and feature flags for differences.
• Eclair: strong routing and mobile-focused tooling through ACINQ’s ecosystem; behavior may differ around pathfinding and batching.

Always test on a small setup first. For instance, if you copy a fee policy from CLN to LND, route some test payments to confirm the ppm math and timing match your expectations.

How often does he post?

It depends. When specs evolve (like Offers/BOLT12 or splicing discussions) or when a real-world issue needs attention, expect thoughtful write-ups. That cadence tends to mirror meaningful protocol movement, which is exactly when you want context.

Is he biased toward Core Lightning?

He writes from hands-on experience with Core Lightning, which is useful because the examples are real and the trade-offs are honest. That said, you’ll get the best results if you cross-check details with your implementation’s docs and run your own small tests. The principles are broadly applicable; the knobs vary.

Where should I follow updates?

Here’s a simple way to stay current without getting overwhelmed:

• Rusty’s Medium:https://medium.com/@rusty_lightning
• BOLT specs and discussions: watch issues/PRs for Offers, onion messaging, and pathfinding topics on the Lightning RFCs GitHub.
• Your client’s release notes: CLN, LND, and Eclair updates tell you what’s actually shippable now.

One more reason to keep an eye on this: in recent measurements shared by operators and public reports, success rates and costs are improving as implementations iterate on pathfinding and liquidity tools. For example, River’s 2023 analysis reported high payment reliability across large sample sizes and emphasized how liquidity policy fine-tuning boosted success—exactly the kind of practical outcome you can reproduce by applying fee and liquidity strategies thoughtfully.

Any quick proof that these concepts matter in the real world?

Two simple ones I’ve seen repeatedly:

• Fee policy changes traffic: nudging ppm down on well-connected outbound channels consistently increases successful forwards within hours or days, which you can see in your forwarding logs.
• Offers improve UX and privacy: reusable offers remove invoice churn and reduce metadata exposure, which helps merchants who accept many small payments (think content tipping or micro-sales).

These aren’t just theory—they show up in route success rates, settlement latency, and fewer manual invoice headaches.

What should I read if I only have 20 minutes?

Skim a post on routing and channel balance, then one on fee thinking, then a quick piece on Offers. You’ll leave with a mental model of “how money moves,” “how to influence it,” and “how to make payments easier to request.” That’s enough to run one experiment today.

Pro tip: make one small change, measure it for a few days, and keep a short log. Improvement compounds—and so does your confidence.

Want a tight, no-fluff checklist to turn this into action today? That’s next—stick with me for the final section.

Final notes, next steps, and how I’d use this guide

You’ve got enough to move from reading to results. The trick now is to keep it small, measurable, and safe. Here’s exactly how I’d put this into motion without burning weekends or risking production.

Your action checklist

• Pick your lane (today): Are you learning fundamentals, running a node, or building features? Lock that in for the week.
• Choose two posts that match your lane: Open them, skim once for the main idea, then mark the key trade-offs you want to test.
• Spin up a sandbox: Use Polar or regtest with two implementations (e.g., Core Lightning and LND) and at least three channels so you can see real routing behavior.
• Test one change: For example, experiment with a zero base fee and adjust ppm within a narrow band, or try an Offers (BOLT12)-style flow on testnet. Keep the rest of your setup constant so you can attribute outcomes.
• Measure three metrics only: payment success rate, median fee paid/earned, and time-to-finality. That’s enough to know if you’re improving.
• Write a 10-line summary: problem, hypothesis, change, metrics before/after, decision. This becomes your growing playbook.
• Roll out safely: introduce changes to a small slice of traffic or one channel group, set a rollback trigger (e.g., −10% success), and keep logs for 72 hours.

Tip: River’s operations team has published data showing Lightning payments can be highly reliable when liquidity is managed well, and research from Pickhardt & Richter highlights how fee policy and path probabilities affect success. Use that as motivation to test changes methodically—your numbers can get there too.

• Read:River research on Lightning reliability and cost
• Research:Optimally Reliable and Cheap Payment Flows (Pickhardt & Richter)

Concrete example you can try this week:

• Baseline for 48 hours: log success rate, average ppm, and failure reasons (insufficient liquidity vs. no route).
• Set base fee to 0 on one outbound channel group, narrow ppm to a tighter range, and add 10–20% more outbound liquidity to your busiest peer.
• Compare: Did failures for “insufficient capacity” drop? Did revenue per sat of liquidity improve? If yes, expand slowly; if not, revert and adjust liquidity placement instead of fees.

Common pitfalls to avoid

• Copying someone else’s settings blindly: Your channel graph, peers, and traffic pattern are unique. What works for a top router might be terrible for a boutique node.
• Skipping the sandbox: Even small config flags can change behavior across implementations. Test on regtest/testnet first. Always.
• Ignoring backups and keys: For LND, keep a fresh Static Channel Backup off the node. For Core Lightning, back up hsm_secret and the database, and document the restore process. Do one restore drill now, not later.
• Underestimating liquidity placement: If payment failures rise, fees might be fine—your liquidity might just be in the wrong place. Shift capacity to the peers that actually route for you.
• No rollback plan: Before you change anything, write the exact condition that makes you revert. Then stick to it.

“Good ops” = one change at a time, measurable impact, clear exit ramp.

When to ask for help

• If you’re stuck for more than a day: sanity-check against specs and your client’s docs before shipping.
• Bring a minimal repro: config snippet, exact error, logs, versions, and the last known good state. You’ll get better answers, faster.
• Use the right channels:

  • BOLT specs on GitHub — confirm intended behavior
  • Lightning-Dev mailing list — protocol-level questions
  • Core Lightning repo and docs — implementation specifics
  • Bitcoin Stack Exchange — troubleshooting with searchable history

A mini runbook I keep handy:

• Define the goal (e.g., +1% success or −10% median fee).
• Change one variable (fee, liquidity location, feature flag).
• Measure for a fixed window (24–72 hours).
• Decide: roll forward, roll back, or gather more data.
• Document and move on to the next experiment.

Conclusion

Rusty Russell’s Medium is one of the best places to understand how Lightning really works. Use this plan to pick the right posts, turn ideas into small experiments, and make smarter choices for your node, app, or business. If this helped, keep me on your radar at cryptolinks.com/news—I’m always testing, summarizing, and sharing what moves the needle so you can stay ahead without living in your terminal.