Lightning Stream · ProgressProgress and status

1Status and limits

Released

One app for buying and selling, for Umbrel (a community store of ours), StartOS (our registry, https://registry.lazarus-xbt.xyz) and Linux (Docker Compose). The current version and every change are in the changelog; Try it has the setup.

On mainnet

Since 26 October 2026, between our own nodes: a fresh install from the published packages bought films and AI answers from our shop, a node box of ours bought from a second shop of ours, and a rental of hashrate was paid, every charge matching the meter to the millisatoshi. On StartOS the app's node key, through Lightning Fork's grant, was tested on mainnet; a paid buy there has not run yet. See On mainnet. Nobody outside the project has used it yet.

Reviewed, not audited

Chris Guida reviewed the earlier design and its published code in October 2026, and then, in a second review that read the code without running it, the ticket design, the lottery and the tree as they stood on 13 October; the move onto Lightning and most of Draft 9 follow from his two reviews. Kyle Santiago read the design and pointed out the slot and dust limits the defaults are built around. In October 2026, machine-assisted reviews of the payment code found further faults, among them a way for another page on the same machine to start a payment, and bookkeeping that could undercount after a restart; all are fixed in 0.1.15. Nobody outside the project has reviewed the fixes, and there has been no independent audit. The win that pays itself waits for a cryptographer's reading. Treat it all as unaudited software.

Next

A small test with people outside the project, by invitation, with amounts they can afford to lose; then a paid buy on StartOS, and the open items below.

Trade-offs

Money moves a ticket at a time, and the buyer can lose one ticket. Unused held tickets are locked until cancelled or expired, and unspent prepaid credit stays with a seller until the buyer returns. A seller needs an lnd-family Lightning node with room to receive, online while it serves; a Core Lightning node cannot sell held tickets today. Paid by lottery, income and cost are uneven in the short run. The Lightning nodes on both sides hold hot keys. XBT's Lightning network is young and small, so a route may not exist; a direct channel to the shop always works.

2Built and not built

Released, in the app

• The wallet and its spending rules: budgets, per-seller caps, an approval threshold, allowed sellers only, all signed by the owner with an approval key; safe starter rules; a confirmation before it pays with real money.
• Prepaid and held tickets on both sides, metered to the millisatoshi, with a signed receipt for every answer, and credit kept with a seller across restarts and address changes.
• Selling: a gateway in front of the box's own services (media, an AI model, any web service) at prices the owner sets, published as signed listings on Nostr.
• Buying: Browse and a player for films, AI answers, and hashrate.
• Hashrate: a hashmaker rents out miners and a hashtaker rents them into its own DATUM Gateway, paying for each slice after it is delivered.
• Agents: the same wallet over MCP.

Built, not in the app's everyday path

The lottery, in the form where the buyer pays after a win, run on a regtest with 100 sellers paid at once (The lottery as built). Pay with work, where a miner pays with pool shares.

Planned

The AI model offered to Nostr clients as a data vending machine (NIP-90), and the app buying from such machines within its rules. Paying from a wallet over Nostr Wallet Connect instead of a node of one's own. Ranking and search on Browse. A guard in the hashmaker that stops a rental when a hashtaker's work stops following the public chain, against a majority attack. A seller's own web app inside the app. None of these is released.

Not built

The win that pays itself: not before a cryptographer has reviewed the argument it rests on. Fair exchange on held tickets. A seller's software for a Core Lightning node.

3Packages for node boxes

Most people who run a Lightning node run it on a home box. Lightning Stream is one app on each: it buys, sells and rents hashrate, beside the box's own Knots-BLAKE2b and Lightning Fork, which come from Paul's store and registry. The images it runs are published on GitHub's container registry for three kinds of processor, and each package names its images by digest, so a box gets exactly the image that was checked.

Umbrel

From our community store. The app makes its own narrow keys on the box's node, so there is nothing to paste. An update keeps your keys, rules and settings.

StartOS

From our registry, with Lightning Fork from Paul's registry, https://start9.paulscode.com/. The app asks Lightning Fork for its own key through Lightning Fork's Grant app access, which Paul built: the owner approves it there, and can revoke it there. The key can pay and read, and nothing more. Selling still needs the shop's invoice keys pasted on the Sell page.

Linux

Docker Compose beside your own Knots and Lightning Fork, from the same images, with a guide in the source tree (docs/LINUX.md). On a Raspberry Pi 4 all eight of its containers started in about 10 s and idled in 18 MB of memory together, measured before a node was attached.

An https address for a shop

Buyers pay a shop only over https with a publicly trusted certificate. The Sell page helps the owner get one; a shop reached only over Tor cannot be paid yet.

4The earlier design

The first version of Lightning Stream did not carry payments over Lightning. It used its own one-way payment channel on the chain: Jeremy Spilman's channel of 2013 [1], in the CHECKLOCKTIMEVERIFY form that BIP 65 gives as one of its examples [2]. The buyer locked coins once in an output on the chain, signed a slightly larger running total for every piece, and the seller settled once. To reach many sellers with one channel it added a hub, with each forwarded payment locked by an adaptor signature [16][17][18]. A hub that forwards payments it cannot take was not new either: TumbleBit [19] and A2L [20] are its ancestors.

Chris Guida's review of the published code (October 2026) found the hub the weakest part. One-way channels with no revocation give a hub nothing to fall back on when a channel closes or is replaced while a payment is in flight, and that is the problem Lightning's commitment protocol [3] was built to solve. The review advised using Lightning for what a network is good at, reaching many sellers, and keeping the direct channel as a fast path. We went further and moved the whole payment path onto Lightning.

The hub is retired

Its code, tests and packages have been removed from the tree, and they remain in its history, last at commit 0911cc0. Lightning's own routing replaces it. The 59 stated limits that belonged to the hub, to the hub beside a Lightning node and to the routed client go with it.

The on-chain channel is removed

It was frozen on 11 October 2026, when the payment path moved onto Lightning, and nothing new was built on it after that. Once tickets ran end to end and the lottery was built, it was taken out of the tree, later in October 2026: tickets and the lottery do its job on Lightning, and the channel carried the open defects that were left. With it went its provider and its client, the wallet's channel rail, the light client that watched the chain for it, the fair exchange built on its states (Paying only for what checks out), the flow in which a paid call waited for the owner's approval (A wallet for agents), and their tests, vectors and scripts. The code stays in the history, last at commit 1ad0c48. The two Python reference repositories still hold the channel.

What the removal leaves behind

Three things. A wallet that was upgraded with channels on record cannot close or refund them with this version: it leaves their records and sealed keys untouched and says which revision settles them. The wallet pays sellers over Lightning only; its Umbrel and StartOS packages have since been redone to use the box's Lightning node (Packages). And the channel's one remaining case, a seller who cannot run a Lightning node, is given up: such a seller has no rail here, and pay with work is the other way in. Nobody has reviewed the removal.

What the channel did that tickets do not

It settled each piece exactly, it left nothing in flight when a buyer stopped, and its seller needed no Lightning node. Tickets give those three up, as What it gives and what it costs says. What they bring is Lightning's routing in place of a hub, and no transaction on the chain for each buyer and seller.

An earlier draft of this paper had a section, "Beside Lightning", which argued that Lightning could not hold a buyer's coins under a lock for the length of a session. Hold invoices do that, for a ticket at a time. That section no longer describes Lightning Stream.

5Changes by draft

Draft 11, 27 October 2026

The app is released, and these pages say so. The whitepaper is shorter, a new page, Try it, has the setup, and Tests and numbers has the first runs of the released app on mainnet. Tickets are now about 900 sat, so a ticket and its fee fit under the starter rules' approval line.

Draft 10, 22 October 2026

The whitepaper is cut to the idea, and the detail moved to four pages: design details, tests and numbers, this page, and uses. Nothing in the design or the code changed with it.

Draft 9, 18 October 2026

Answering a second outside review, with packages for node boxes. Most of what was new came from Chris Guida's second review: the claim of "no change to the node" is narrowed to the nodes it holds for (How a ticket works); the costs are given at three fee rates, with a floor for held tickets that follows from them (Fee rates); a seller the owner has not named is paid a prepaid ticket first; the lottery's limits are tighter and its horizon is stated (The lottery); the software refuses mainnet unless it is asked for; the evidence can be checked from outside; and there are packages for Umbrel and StartOS (Packages).

Back to the whitepaper · Draft 11, 27 October 2026.