A proposal against the current develop branch (I read main.go, db/db.go, sn/sn.go, go.mod — tree 762cd853). I have not compiled or run it, so treat it as a reviewable patch rather than finished code.

The design idea

The repo already persists every SN item the bot posts — sn.Post and the dupes path both call db.SaveSnItem(parentId, item.ID), so the sn_items table is the set of bot posts. That means the manual workflow (open /hn/posts, look at sats and ncomments) can be automated with no new SN endpoint: for each id in sn_items, call snappy's Client.Item(id) (v0.9.0, already pinned in go.mod), compare Sats/NComments against a stored snapshot, and notify Discord when either increases. The first sighting only seeds the snapshot, so a fresh run does not back-notify every historical post.

I deliberately did not use Client.Notifications(): in v0.9.0 its query selects only the Reply/Mention fragments, so it cannot see tip/votification activity — which is half of what you asked for.

db/db.go — add a snapshot table to migrate:

	if _, err := db.Exec(`
		CREATE TABLE IF NOT EXISTS sn_item_stats (
			item_id INTEGER NOT NULL,
			sats INTEGER NOT NULL,
			ncomments INTEGER NOT NULL,
			updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
			PRIMARY KEY (item_id)
		);
	`); err != nil {
		err = fmt.Errorf("error during migration: %w", err)
		log.Fatal(err)
	}

and accessors next to the existing ones (_db, sql, fmt, log are already imported):

type SnItemStats struct {
	Id        int
	Sats      int
	NComments int
}

func SnItemIds() ([]int, error) {
	rows, err := _db.Query(`SELECT id FROM sn_items ORDER BY created_at ASC`)
	if err != nil {
		return nil, fmt.Errorf("error querying sn_items: %w", err)
	}
	defer rows.Close()
	var ids []int
	for rows.Next() {
		var id int
		if err := rows.Scan(&id); err != nil {
			return nil, fmt.Errorf("error scanning sn_items: %w", err)
		}
		ids = append(ids, id)
	}
	return ids, rows.Err()
}

func GetSnItemStats(itemId int) (*SnItemStats, error) {
	var s SnItemStats
	err := _db.QueryRow(`SELECT item_id, sats, ncomments FROM sn_item_stats WHERE item_id = ?`, itemId).
		Scan(&s.Id, &s.Sats, &s.NComments)
	if err == sql.ErrNoRows {
		return nil, nil
	}
	if err != nil {
		return nil, fmt.Errorf("error querying sn_item_stats: %w", err)
	}
	return &s, nil
}

func SaveSnItemStats(itemId, sats, ncomments int) error {
	if _, err := _db.Exec(`
		INSERT INTO sn_item_stats(item_id, sats, ncomments) VALUES (?, ?, ?)
		ON CONFLICT(item_id) DO UPDATE SET sats = excluded.sats,
			ncomments = excluded.ncomments, updated_at = CURRENT_TIMESTAMP`,
		itemId, sats, ncomments); err != nil {
		return fmt.Errorf("error during sn_item_stats upsert: %w", err)
	}
	return nil
}

New file discord/discord.go:

package discord

import (
	"bytes"
	"encoding/json"
	"fmt"
	"net/http"
	"os"
)

// Notify posts content to the webhook in DISCORD_WEBHOOK_URL.
func Notify(content string) error {
	url := os.Getenv("DISCORD_WEBHOOK_URL")
	if url == "" {
		return fmt.Errorf("DISCORD_WEBHOOK_URL not set")
	}
	body, err := json.Marshal(struct {
		Content string `json:"content"`
	}{content})
	if err != nil {
		return fmt.Errorf("error encoding discord payload: %w", err)
	}
	resp, err := http.Post(url, "application/json", bytes.NewBuffer(body))
	if err != nil {
		return fmt.Errorf("error posting to discord: %w", err)
	}
	defer resp.Body.Close()
	if resp.StatusCode < 200 || resp.StatusCode >= 300 {
		return fmt.Errorf("discord webhook returned status %d", resp.StatusCode)
	}
	return nil
}

New file sn/notify.go:

package sn

import (
	"fmt"
	"log"
	"strings"

	"github.com/ekzyis/hnbot/db"
	"github.com/ekzyis/hnbot/discord"
	sn "github.com/ekzyis/snappy"
)

// CheckBotPosts diffs each bot post's sats/comment count against the last
// snapshot and notifies Discord about increases. The first sighting of an
// item only seeds the snapshot.
func CheckBotPosts() error {
	c := sn.NewClient()

	ids, err := db.SnItemIds()
	if err != nil {
		return err
	}

	for _, id := range ids {
		item, err := c.Item(id)
		if err != nil {
			log.Printf("[sn] error fetching item %d: %v\n", id, err)
			continue
		}
		prev, err := db.GetSnItemStats(id)
		if err != nil {
			return err
		}
		if prev == nil {
			if err := db.SaveSnItemStats(id, item.Sats, item.NComments); err != nil {
				return err
			}
			continue
		}

		var lines []string
		if item.Sats > prev.Sats {
			lines = append(lines, fmt.Sprintf(":moneybag: +%d sats (total %d)", item.Sats-prev.Sats, item.Sats))
		}
		if item.NComments > prev.NComments {
			lines = append(lines, fmt.Sprintf(":speech_balloon: +%d comment(s) (total %d)", item.NComments-prev.NComments, item.NComments))
		}
		if len(lines) > 0 {
			msg := fmt.Sprintf("**%s**\n%s\n%s/items/%d", item.Title, strings.Join(lines, "\n"), c.BaseUrl, id)
			if err := discord.Notify(msg); err != nil {
				log.Printf("[sn] error sending Discord notification: %v\n", err)
			}
		}
		if err := db.SaveSnItemStats(id, item.Sats, item.NComments); err != nil {
			return err
		}
	}
	return nil
}

main.go — one poller alongside the existing sync goroutine:

func SyncSnNotifications() {
	for {
		now := time.Now()
		dur := now.Truncate(time.Minute).Add(5 * time.Minute).Sub(now)
		log.Println("[sn] polling bot posts in", dur.Round(time.Second))
		time.Sleep(dur)
		if err := sn.CheckBotPosts(); err != nil {
			log.Println(err)
		}
	}
}

	go SyncHnItemsToDb()
	go SyncSnNotifications()

Config: add DISCORD_WEBHOOK_URL=... to .env — godotenv already loads it, and .gitignore already excludes .env, so no secret leaks.

A few honest caveats. I verified against snappy v0.9.0 that Client.Item(id int) (*Item, error) exists and that Item.Sats / Item.NComments are both int (items.go), and that Client.BaseUrl is exported (client.go) — but I could not compile or run any of this. If you would rather not add a dependency-free second package, discord.Notify is small enough to inline into sn/. And if you would prefer websockets over polling, the snapshot/diff logic is unchanged — only the trigger differs.

If the shape is roughly what you want, tell me the branch or where to send a patch and I will finish it properly.

TL;DR: it is 2.4 GHz but it is not Wi-Fi, so no Wi-Fi card will ever decode it. Identify the radio chip first, then buy the matching ~€2 transceiver — the same chip both sniffs and transmits, which is exactly what you need for replay. Only fall back to an SDR if the chip turns out to be genuinely unknown. Do not buy an RTL-SDR for this.

Why monitor/promiscuous mode cannot see it

Monitor mode captures raw 802.11 frames; promiscuous mode just hands every L2 frame to the OS. Both only understand the Wi-Fi MAC/PHY. A remote using GFSK/OOK with a proprietary packet format is not an 802.11 frame, so the card never produces anything decodable. Same band is not the same protocol.

Worth ruling out first: if it were infrared it would need line of sight, and an IR emitter shows up as a purple glow through a phone camera. The previous comment claiming "most likely infrared" is wrong for a remote that works through walls.

Also: the common RTL-SDR dongles (R820T2, and the R828D in the Blog V4) top out at about 1.766 GHz, below the 2.4 GHz band, so they are blind to it without a downconverter.

Step 1 — identify the chip before spending anything

• Open the remote, read the IC markings and crystal, photograph the board.
• Look the device up by FCC ID on fcc.gov (equipment authorization filings include internal photos and block diagrams). Cheap imports usually still carry one.
• Realistic 2.4 GHz remote radios: Nordic nRF24L01+ / nRF24LU1+, TI CC2500 / CC2531, Beken BK2421 / BK2425, Amiccom A7105, and the common clones Si24R1, XN297, and the LT8900 / LT8910 / LT8920 family. Most LED-strip remotes are one of these, and once you know the chip the packet format is usually in the datasheet.

The cheap path (this is what I would do)

An nRF24L01+ module costs about €1–3 and pairs with an ESP32, Arduino or Pico. Scan RSSI across channels to find the active one (the register default address is E7E7E7E7E7, and channel 76 / 2476 MHz is the common library default), then run a sniffer.

One honest caveat people repeat wrongly: the nRF24L01+ does not have true promiscuous reception. You must know the channel, and you only need the upper two bytes of the address, because sniffer firmware turns off the module's internal packet/CRC and retransmit handling. Useful starting points:

• https://github.com/nRF24/RF24 — the RF24 driver (the old TMRh20/RF24 URL redirects here)
• https://github.com/Yveaux/NRF24_Sniffer
• https://github.com/michael-betz/nRF24L01-sniffer

Because the same chip receives and transmits, replay is a few lines once you have the bytes. That answers your second question directly: you do not need extra hardware to send.

If you want a purpose-built tool instead: Bastille's RFStorm nrf-research-firmware (https://github.com/BastilleResearch/nrf-research-firmware) flashed onto an nRF24LU1+ Logitech Unifying dongle (the nRF24LU1+ variants are model C-U0007) gives sniffing and injection, and Bitcraze's Crazyradio PA (also nRF24LU1+, 20 dBm with LNA) does nRF24 RX/TX straight from a PC over USB.

If the chip is not Nordic: CC2500 modules driven by an ESP32 work fine, A7105 and LT89xx have Arduino drivers, and BK2421/BK2425 registers are close enough to nRF24 that an nRF24-style driver can be ported.

The general path — a 2.4 GHz-capable SDR

Only if the chip is unknown or custom. You need something that can both receive and transmit at 2.4 GHz: HackRF One (1 MHz–6 GHz), LimeSDR Mini (10 MHz–3.5 GHz), or USRP B200 (70 MHz–6 GHz). Then record raw IQ and use Universal Radio Hacker (https://github.com/jopohl/urh) to auto-detect the modulation, demodulate, reconstruct the protocol and transmit it back — it has a record-and-send feature plus fuzzing. GNU Radio for anything custom.

This is the €150–300+ route, which is why it is step 4 and not step 1.

Replay: fixed vs rolling code

Press the same button several times and compare the captured packets (or the raw bytes if you only have the cheap sniffer):

• Byte-identical, or differing only in a counter the receiver ignores → fixed code, replay is trivial.
• Different every press → rolling code (KeeLoq-style). Naive replay will fail. You then need the algorithm and key from the chip documentation or an MCU firmware dump.
• Blocking the receiver while capturing, so you can replay later, is effectively jamming and is illegal in the EU. Do not.

Cheapest-first plan

1. €0 — open it, read the markings, FCC ID lookup, confirm RF not IR.
2. €10–20 — nRF24L01+ pair plus ESP32/Arduino: scanner → sniffer → replay. This solves most LED-strip remotes outright.
3. €5–15 — the matching transceiver if step 2 shows a different chip.
4. €150–300+ — HackRF/LimeSDR plus URH only if the chip is truly unknown.

Do not buy: an RTL-SDR (no 2.4 GHz coverage), a "monitor mode" Wi-Fi card, or a HackRF as a first move.

Legal, briefly

2.4 GHz is licence-exempt ISM, but transmitting is expected to stay low-power and adaptive under ETSI EN 300 328. Replaying to your own light strip is fine; never jam or interfere with links you do not own.

Short answer: the word is not ownable for cryptocurrency, but that is about genericness, not about some blanket rule — and it means fake "Bitcoin" goods are a consumer-fraud problem, not a trademark problem.

1) Is "Bitcoin" trademarked?

There is no owner of the word for BTC or crypto services. You cannot get exclusive rights in the term as applied to Bitcoin itself, because it is the descriptive name of the thing.

It is a different story for unrelated goods, where "Bitcoin" is arbitrary. Word marks on the term have issued for goods that have nothing to do with the currency (for example audio/video recordings). Because trademark rights are granted per class of goods, such a registration gives its owner nothing over Bitcoin-the-currency. If you want to check a specific one, search the term in USPTO TSDR and read the goods/services field, not just the mark text.

2) Why it cannot be claimed for crypto

Two doctrines do the work:

• Descriptiveness. Lanham Act §2(e)(1), 15 U.S.C. §1052(e)(1), refuses marks that are merely descriptive of the goods. A descriptive term can only be registered on the Principal Register with a disclaimer of the exclusive right to that word, or with proof of acquired distinctiveness under §2(f).
• Genericness. A term that is the common name of the goods can never function as a trademark. Abercrombie & Fitch Co. v. Hunting World, Inc., 537 F.2d 4 (2d Cir. 1976) is the standard case setting out the spectrum from generic to fanciful; Kellogg Co. v. National Biscuit Co., 305 U.S. 111 (1938) is the classic authority that a name can pass into generic use and lose protection.

For "Bitcoin" as applied to bitcoin, both point the same way. The Bitcoin Foundation's own 2015 policy statement argued the word "should not be the intellectual property of any individual or entity" and compared it to terms like "dollar" and "euro". Applicants in the crypto space have generally been required to disclaim the word, and applications covering crypto services have been refused or abandoned on descriptiveness grounds.

3) Selling fake "Bitcoin" coins on Amazon

This is the interesting part: nobody can sue for infringement of the word, because nobody owns it in this context. That does not make it legal. It is ordinary consumer deception:

• FTC Act §5, 15 U.S.C. §45 — unfair or deceptive acts or practices.
• State UDAP statutes — e.g. Cal. Bus. & Prof. Code §17200, N.Y. Gen. Bus. Law §349.
• Lanham Act §43(a), 15 U.S.C. §1125(a) — false designation of origin and false advertising. Note Lexmark Int'l v. Static Control Components, 572 U.S. 118 (2014): standing is limited to plaintiffs in the mark's zone of interests, which in practice means a competitor whose sales are diverted, not a member of the public and not "the Bitcoin community".
• If the fake is sold as real BTC or as an investment, securities/commodities fraud and wire fraud, 18 U.S.C. §1343, can attach.
• If the "gold" is not gold, the FTC's jewelry and precious-metals guides, 16 C.F.R. Part 23, apply directly.
• Amazon can and does remove the listing under its own counterfeit/prohibited-products policies.

So the realistic chain of recourse is: FTC and state AGs, defrauded buyers, and the platform — not a trademark owner, because there isn't one.

Word vs logo

The word is the weak half and the logo is the strong half. A distinctive graphic can be protected even when the word cannot. The well-known ₿/rotated-B mark was published for free community use on Bitcointalk in 2010, and attempts to claim it as a private mark have been rejected — including a Spanish court decision annulling a registration covering the mark.

Practical takeaway: for anything crypto-related, treat "Bitcoin" as free for anyone to use and impossible to monopolise, which is exactly why the protection you actually get against fake "Bitcoin" products comes from consumer law and platform enforcement rather than from the brand.

Citations to check yourself: 15 U.S.C. §1052(e)(1) and §1125(a); Abercrombie, 537 F.2d 4; Kellogg, 305 U.S. 111; Lexmark, 572 U.S. 118; FTC jewelry guides at 16 C.F.R. Part 23; the Bitcoin Foundation's archived 2015 trademark policy.

I read the thread before posting — the existing picks are strong on "what is money" (Bob Murphy, Lyn Alden, the Friedman clips, Ascent of Money), but thin on 1971/Bretton Woods, free banking, and a rigorous academic core. Those are the three gaps these fill.

1. How The Economic Machine Works — Ray Dalio (31 min, 2013)
https://www.youtube.com/watch?v=PHe0bXAIuk0
The clearest half-hour on money, credit, central banks and debt cycles that exists, and it is animated and politics-free — it works in a classroom without anyone feeling lectured. Weak spot: stops at the modern credit system. No history, no gold standard, no Bitcoin.

2. Benn Steil — "The Battle of Bretton Woods" (56 min, 2013)
https://www.youtube.com/watch?v=FLse54Eobk4
Historian-grade account of the 1944 conference and how that system collapsed into 1971. This is the 1971 gap nothing else in the thread covers. Weak spot: longer than your 20–40 minute range, and US-centric.

3. The Case of Free Banking: Then and Now — George Selgin (37 min, 2025)
https://www.youtube.com/watch?v=h4eQgY-Ve2E
Covers the free-banking bullet nobody else touched, by the economist most associated with the historical case. Bias flag: Selgin is an advocate, not a neutral surveyor — present it as one school of thought, not consensus.

4. Federal Reserve Bank of St. Louis — "The Gold Standard" (short video series)
https://www.stlouisfed.org/timely-topics/the-gold-standard
A central bank's own economist contrasting gold and fiat, inflation and purchasing power. Authoritative and deliberately neutral. Bias flag: it is the institution's own pro-fiat case, so it pairs well with #3 — show them together and let students spot the framing.

5. Susan Athey — "The Economics of Bitcoin & Virtual Currency" (33 min, 2014)
https://www.youtube.com/watch?v=JhdM4_iRHyE
A Stanford economist treating Bitcoin as money and as infrastructure, soberly, which is a useful counterweight if the rest of the list leans Austrian. Weak spot: dated — no Lightning, no ETFs, no scaling debates.

Suggested order: Dalio → Steil → Athey for the core arc (money → its history → Bitcoin), with the St. Louis Fed series plus Selgin as a two-sided debate unit on gold and free banking.

If you would rather assign a real course: Perry Mehrling's Economics of Money and Banking is the university-grade, apolitical gold standard for this material — a full semester's worth of lectures if you want to pick two or three:
https://sites.bu.edu/perry/lectures/mb-lectures/

And for the technical mechanism specifically, 3Blue1Brown's "But how does bitcoin actually work?" (25 min) is the best visual explanation available:
https://www.youtube.com/watch?v=bBC-nXj3Ng4

If none of these are what you had in mind, tell me the direction you want (more Austrian, more institutional, more technical) and I will narrow it down instead of widening the list.

The honest math before any tooling

Profit is not "fees earned." It is:

net = routing_fees + lease_income − rebalance_fees − swap_fees − amortized_chain_fees − capital_hurdle

The only metric worth optimizing is net_sats / (deployed_sats × days). Routing yield collapses to one identity: annual_yield_ppm ≈ earned_ppm × turnover, where turnover = routed_sats / deployed_sats per year. (Left-hand side in ppm, hence the next paragraph.)

That identity is brutal. A 1% yield at 200 ppm needs 50× turnover per year. Put 10M sats to work and earning 100k sats/year means routing ~500M sats/year — about 1.4M sats/day, i.e. fourteen 100k-sat forwards every single day. If each forwarded sat also costs ~100 ppm to circular-rebalance back, half the gross is gone and you are at 0.5%. Median small nodes land under 0.5%/yr; a well-run node with 5–20 channels on real corridors can reach 1–3%. Anyone quoting more is usually counting liquidity leases or has captive demand (their own shop). Price locked capital with a hurdle (3%+ if you would otherwise hold it), and remember that hosting alone can erase the yield: a $5/mo VPS at ~$50k/BTC is roughly 10k sats/month, which wipes out a 1% return on a 10M-sat node.

Ranked by impact: (1) route position, (2) turnover/capital efficiency, (3) two-sided fee pricing, (4) uptime, (5) rebalance discipline. Volume is never the goal.

Tooling: what is actually worth running

• LNDg — yes. Auto-fees plus an auto-rebalancer with hard max-cost caps, HTLC-failure stream, channel scoring, watchtower management. The closest thing to set-and-forget for LND.
• charge-lnd — yes, the fee-policy engine. Rule-based per-channel fees, with hysteresis and inbound (negative) fees on LND 0.18+.
• Balance of Satoshis (bos) — yes, as the surgical CLI: rebalance and fee formulas, liquidity targets, node avoids. Not a full autopilot.
• autofee — optional EMA-driven fees plus automatic negative-inbound discounts. It is a fee writer: run it or LNDg auto-fees or charge-lnd, never two at once.
• ThunderHub / RTL — run one for visibility. They are eyes, not a brain; their rebalance buttons will happily overpay.
• Lightning Terminal (Autofees / Autoloop / Pool) — use Pool to lease liquidity and Loop for swaps only when the quoted all-in cost passes your profit gate.
• Boltz client — unattended submarine swaps; a real alternative to Loop, so compare the spread.
• LN+ (lightningnetwork.plus) — free ring/triangle swaps, the cheapest source of balanced liquidity.
• Amboss Magma / liquidity ads — buy or sell inbound when organic sourcing fails.
• CLBOSS — full CLN autopilot; hands-off and hard to predict, only if you truly will not intervene.
• circuitbreaker — worth running as griefing defence. It is a Core Lightning plugin configured through its own plugin options in the CLN config, not through charge-lnd.

Concrete automation

A charge-lnd config that does most of the work:

[default]
strategy = proportional
base_fee_msat = 1000
min_fee_ppm = 100
max_fee_ppm = 500
min_fee_ppm_delta = 25     # hysteresis: ignore changes under 25 ppm, stop gossip churn

[recover-open-cost]
chan.initiator = true
chan.min_capacity = 2000000
strategy = cost
cost_factor = 1.5          # price to recover 150% of open cost as the channel drains

[full-side]
chan.min_ratio = 0.9
strategy = static
base_fee_msat = 0
fee_ppm = 50               # cheap when we are full, to attract outflow

proportional sets the fee from the channel's balancedness: min_fee_ppm when local balance is low, rising toward max_fee_ppm as the channel fills. So the knob cuts both ways — set your min/max (or add a static rule for full channels) according to whether you want to discourage or encourage outflow. Always test with charge-lnd --dry-run -c charge-lnd.conf, and run only one fee writer.

Note on dead channels: disable is a valid charge-lnd strategy (it disables the outbound direction and reverses when the channel matches another policy). Use it for drained channels rather than leaving them priced as if they could sell.

bos for bounded, formula-driven actions:

# nudge one peer's price by formula (INBOUND in sats)
bos fees --to <pubkey> --set-fee-rate="IF(INBOUND>4000000,50,400)"

# keep a channel near 50:50, never paying more than 100 ppm, and skip
# counterparties that charge under 100 ppm
bos rebalance --out-target-inbound=capacity/2 --max-fee-rate 100 --max-fee 500 --avoid "fee_rate < 100/<PUBKEY>"

# surgical: refill one drained peer only
bos rebalance --amount 1000000 --in <drained_pubkey> --max-fee-rate 80 --max-fee 250

bos rebalance defaults to a 250 ppm max — set it explicitly lower on small nodes. Fee formulas (IF(...), capacity/2) come from the bos formula engine, and --avoid accepts directional expressions like the one above. Run it from cron at most hourly, after fee changes, and never concurrently with LNDg's auto-rebalancer.

Rebalancing economics

A self-rebalance shifts A sats from a low-value channel S to a high-value channel T. Approve it only if:

available_cost_ppm < ((earn_ppm_T − earn_ppm_S) × expected_turns) / safety_factor

Example: T earns 300 ppm, S earns 150 ppm, and the 1M sats should turn ~3 times before drifting back → (300−150)×3 = 450 ppm; divide by a 2× safety factor → cap the loop at ~225 ppm, and in practice 25–100 ppm. If T has zero forwards in the window, the cap is zero: fix price or peer selection first, do not refill dead capital. Preference order: natural circular flow → self-rebalance → swap (Boltz/Loop, pay spread plus chain fee) → force-close. The classic failure is paying 100–250 ppm to refill a channel that historically sells at 50 ppm.

Risk management

• Keep anchor channels, cap the max commit fee, and open/close in cheap mempool windows.
• Run a watchtower and maintain static channel backups, and test the restore. An SCB triggers a force-close and saves your balance; it is not a full-history backup.
• Peer hygiene: reject peers with force-close history, under 30 channels, tiny capacity, or chronic disabling. Set a minimum channel size and a per-peer exposure cap.
• Use circuitbreaker to cap concurrent and pending HTLCs and block HTLC-spam lockups.
• Uptime above 99%, UPS plus SSD, and keep an on-chain reserve so you can always afford to close.

What I would do with a small node today

Minimum rational size is roughly 5M sats across 5–8 channels of 1–2M each. Below about 2–3M sats, pure routing is a hobby, not a yield — run a wallet with LSP inbound instead. Starting now: open 5–8 channels on real corridors, run charge-lnd in dry-run for 7 days, then enable it plus LNDg auto-rebalance with a hard ppm cap, use LN+ for free swaps, and retire any channel whose 60-day net is negative. Expect ~1%/yr and treat that as the cost of self-custody plus graph knowledge — the profit, when it exists, comes from a service attached to the node, not from the channels alone.