Lightning Stream · DesignDesign details

1Tickets in detail

The steps of a ticket, in full. The whitepaper has the short version and the figures.

Terms

The seller answers the first request with its price and terms: its Lightning node, the size of a ticket, how many tickets it will hold for one buyer, and how long a ticket lives.

Lock

The wallet makes one secret for each ticket and sends the seller only the hashes. For each hash the seller's node issues a hold invoice: an invoice that can be paid but not collected until its secret is shown. Hold invoices are not ours: Joost Jager added them to lnd in 2019 [5]. The wallet checks each invoice (who is paid, how much, that it is an XBT invoice, and that it expires no later than the owner allows) and pays it through the owner's Lightning node.

Pay

When the balance with the seller runs out, the wallet releases the next secret. The seller hashes it, confirms that the matching ticket is locked, collects it, and adds a ticket's worth to the session's balance. Requests are served from that balance: inside one ticket, pieces are counted in millisatoshis against a running total that the seller signs in its receipt. Where a secret travels has one answer: in a short request of its own within the session, a release, which asks for no resource. Every seller must accept a secret there, and the wallet sends one nowhere else. The draft wire also lets a seller take a secret inside a paid request; the gateway built here does, but a seller that took secrets only there could not be paid by this wallet. One path means one signed answer to each secret, and a request that is refused or lost has cost no secret.

Refill

The wallet keeps two tickets locked. When one is left it locks the next in the background, which took about a fifth of a second through one routing node. No request waits for a payment.

Stop

The wallet tells the seller it is done, and the seller cancels the unreleased tickets, which frees the buyer's money at once. If the seller does not, a Lightning Fork seller's node cancels each ticket 18 blocks before the ticket expires, or the ticket times out along the route. The 18 is a setting of the node's runner (lnd's invoices.holdexpirydelta, 12 on upstream lnd), which the gateway cannot read, so it takes the number from its config and refuses to start above 18.

Which nodes can sell. A ticket needs three calls on the seller's node: make a hold invoice, collect it, cancel it. lnd and its forks have all three as they ship, so they need no change; of them only Lightning Fork was run. A Core Lightning node cannot be a seller's node for held tickets today, for four reasons. It has no hold-invoice call of its own. Of the two published hold plugins, one issues invoices without XBT's feature bit, which a Lightning Fork buyer refuses, and the other keeps the secret on the seller's node, where a ticket's secret must be the buyer's. Nothing on it cancels a held ticket before the ticket expires: in our lab, a Core Lightning seller that neither collected nor cancelled ended with the buyer's node force-closing its own channel to it. And the gateway speaks to lnd-family nodes only, and will not start against any other. As a buyer's node or a routing node a Core Lightning node needed nothing.

By default the buyer goes first: it releases a ticket before the requests it pays for, so the seller risks nothing and the buyer risks one ticket. For content that can be checked piece by piece the order turns round: the buyer checks the piece, then releases the ticket, and it is the seller who risks one piece (see Paying only for what checks out). The seller's terms say which order applies.

A seller the owner has not named. An owner cannot name every seller an agent may find, and a seller cannot know a buyer that has never paid it. So since 17 October 2026 a session with such a seller starts with one prepaid ticket: an ordinary payment that the seller collects as it arrives, which holds nothing on any channel. The wallet holds tickets with that seller only after its own node shows the prepaid one paid, and then one at a time, against two with a seller the owner named. A seller the owner has not named that offers no prepaid tickets is not held with at all, and is paid by the next way its terms offer, such as the lottery. The seller's side has the same rule from the other end: the gateway issues hold invoices only to a session that has paid it something, so a buyer it has never been paid by gets no held place. Before that rule, 2,000 lock requests from one client took every held place of a gateway in half a second, and cost that client nothing (measured on a regtest lab, our own nodes). Since then a lock for held tickets from a session that has paid nothing is refused, and the invoices of a first lock lapse after 20 s. The rule is built on both sides and in their tests. The gateway's lab script now sends the same 2,000 locks against it, and no report of a run of that check is in the tree yet.

The default settings are 1,000 sat tickets, 2 locked at a time with a seller the owner named and 1 with one it did not, a life of about 40 blocks, and no held ticket under 546 sat, or under a higher floor that follows from the fee rate where a channel without anchors may be on the route (Fee rates). The seller sets them and the owner's policy caps them. Earlier drafts locked 8 at a time. It is 2 now because a locked ticket takes up a place, a slot, on every channel it crosses, and some channels have only 30 slots for everybody who uses them; Slots and dust explains. A buyer that spends faster than two tickets can be refilled takes larger tickets, not more of them.

These steps are the design. They were first run in our lab by scripts driving three Lightning nodes. Since then both sides have been built and run on a regtest: the ticket book in the wallet and the seller's gateway. The wallet now pays a gateway from end to end on a regtest, through a routing node. The code now has the defaults described here; see Built and not built.

2What it gives and what it costs

The measurements in this section come from a three-node regtest lab with one hop: a buyer, one routing node and a seller, all on Lightning Fork, on channels of the anchor type, at regtest's fee rate of 1 sat/vB. The figures for Core Lightning come from a later run on six nodes. What changes at higher fee rates, and on channels without anchors, is under Fee rates. Numbers has the full tables and what was not measured.

What it gives

No request waits for a Lightning payment

Tickets are locked ahead, and a released ticket's balance pays for the requests after it. The seller's check of a secret took 0.93 ms (median) and collecting the ticket 3.5 ms (measured on a three-node regtest lab, one hop). It is not free of round trips: the wallet sends every call once without payment, reads the seller's 402, and sends it again with its payment, and a release is one more request. On loopback paying added 0.3 to 0.4 ms to a call; over a real network every call is one more round trip to the seller, and none of that was measured.

Pieces metered to the millisatoshi

Pieces are counted in millisatoshis, while money moves a ticket at a time: about 900 sat at today's shops, small enough that a ticket and its routing fee stay under the starter rules' approval line of 1,000 sat, and never less than 546 sat for a ticket that is held. The part of the last ticket that was not used stays with the seller as credit, and the wallet spends it first when the buyer comes back. For pieces worth less than a ticket there is a second way to pay: the lottery.

A bounded loss

The buyer can lose at most one ticket, and its routing fee. A ticket that was not released is never paid. A prepaid ticket, the first one with a seller the owner has not named, is spent when it is paid, used or not, and it too is one ticket.

Lightning's reach

A buyer can pay any seller a Lightning route reaches. The routing, the liquidity and the nodes are Lightning's own. Lightning Stream runs no network and no hub.

The owner's policy

The agent still pays under the owner's signed policy and still holds no key. In the lab the node permissions the wallet's Lightning payer already uses were enough to pay tickets. The seller's software needed only the permissions to read and write invoices, and its node refused it when it tried to send coins.

What it costs

Unused tickets are locked until cancelled or expired

A buyer that stops gets its unused tickets back at once only if the seller cancels them. Otherwise it waits: 25 blocks for 40-block tickets when the seller did nothing, 51 blocks through one routing node when the seller vanished (measured on a three-node regtest lab, one hop). At XBT's block spacing of about 7 minutes that is about 3 hours and about 6 hours.

The seller runs a Lightning node

A seller needs an lnd-family Lightning node with inbound capacity, online while tickets are locked. This is a real demand, and it is also the aim of the design: every seller is one more Lightning node on XBT, and more nodes is what the network needs. A buyer needs a Lightning node with a channel, which the wallet's Lightning payer already asks for.

Tickets are held payments

While a ticket is locked it occupies capacity, and one of a channel's payment slots, on every channel along the route. A channel has between 30 and 483 slots in each direction, depending on the node software at each end [4]: 483 between two Lightning Fork nodes, and 30 where either end is a Core Lightning node at its default. A routing node earns a fee only when a ticket is collected, and nothing when it is cancelled. XBT's Lightning network today is two implementations and about forty channels, and there this is tolerable. On a large network it is the behaviour that defences against channel jamming [10] are designed to stop: fees that are paid whether or not a payment completes [11], fees for the time a payment is held [12], and reputation carried with each payment [13]. So tickets must stay few, small and short-lived, and the defaults are modest for that reason. The rules that keep them so, such as the half rule below, are rules of this software: nothing makes another wallet, another seller or a routing node keep them, and a routing node that sees a peer's channel fill with held payments can raise its fees to that peer or close the channel. If hold fees arrive on Lightning, or fees paid whether or not a payment completes, tickets pay them, and a cancelled ticket then costs its buyer something. The written fallback for that day: held tickets are for a seller the buyer stays with, where such a fee is small beside what the session pays, and for a stranger prepaid tickets or the lottery become the only way to pay. Both are built, and the wire needs no change for it. Neither kind of fee exists on XBT's Lightning network today.

Slots are few, and shared

A channel's slots are shared by every buyer, every seller and every ordinary payment that crosses it. In our lab, of 40 tickets offered to a Core Lightning seller on one channel, 30 locked and 10 failed, and while the 30 were held an ordinary payment over that channel failed too. So the wallet holds little: 2 tickets with a seller the owner named, 1 with one it did not, and never more than half the slots of a channel it can see, which is 15 of 30. When a lock fails because a route is full, the wallet does not try harder. It drops to one ticket, waits, and then stops holding tickets with that seller and pays another way.

No small held tickets

A locked payment below a channel's dust limit (354 sat on a Lightning Fork node, 546 sat on a Core Lightning node) cannot be claimed on the chain, and if the channel is force-closed while it is locked, its value goes to the miners. So a held ticket is never under 546 sat. On a channel without anchors the limit rises with the fee rate, and the floor for held tickets rises with it: 2,304 sat through a routing node at mainnet's default (Fee rates). Smaller amounts are not held at all: they are paid at once, by a prepaid ticket or by the lottery. The cost is that a ticket cannot be made small to suit a small seller.

A routing fee per ticket

At the forks' default policy a routing node charges 1 sat, plus one part per million, for each ticket that is collected: 0.1% of a 1,000 sat ticket per hop. With 10 tickets locked and 5 collected, the buyer paid 5,005 sat and the seller received 5,000 (measured on a three-node regtest lab, one hop). What nodes on mainnet charge is not known to us.

The seller must collect on use and stay online

A ticket not collected 18 blocks before its expiry is cancelled by the seller's own Lightning Fork node, and a seller offline when locked tickets expire had its channel force-closed (measured on a three-node regtest lab, one hop).

Hold invoices, BOLT 11 only, lnd-family sellers only

Tickets need a seller's node that can hold a payment. Lightning Fork [61] has hold invoices for BOLT 11 invoices and not for BOLT 12 offers [4]. The other XBT Lightning implementation, the Core Lightning fork [63], works as a buyer's node and as a routing node with nothing added, and cannot be a seller's node for held tickets today. It has no hold invoice of its own: it holds a ticket only through a plugin [67], and neither of the two published hold plugins [68][69] works for tickets on XBT. In our lab a small plugin of our own, a test instrument and not a product, held and collected tickets on it. Nothing on a Core Lightning node cancels a held ticket before it expires. A prepaid ticket needs no hold invoice, so it is what a Core Lightning seller could offer as its node ships, but no seller's software for a Core Lightning node exists here, for prepaid tickets or held ones. The wallet and the gateway speak to Lightning Fork nodes only.

What others can see

No transaction on the chain ties a buyer to a seller, and the seller does not learn the buyer's node. But the nodes along the route see a run of equal payments to one seller and can see when each is released, and every node on a ticket's route sees the same hash.

Slots and dust: why the defaults are small

Think of a channel as a road with a small car park beside it. Every payment on its way parks in one space on each road it travels, and drives off when it is done. An ordinary payment is parked for a fraction of a second. A ticket is different: it stays parked until the buyer uses it or the seller cancels it. The spaces are the channel's slots. They are counted in payments, not in money, so a full car park turns away a payment of any size, however much money the channel holds. And the car park is shared by everyone whose payments use that road.

How many spaces there are depends on the node software at each end of the channel. The protocol allows up to 483 in each direction [4]. Lightning Fork uses 483. Core Lightning uses 30 unless its operator sets another number, and a channel with a Core Lightning node at either end carries 30 each way. The number is fixed when the channel opens. A buyer can read it for its own channels. For a channel further along the route it cannot: it finds out only when a payment fails there.

Our first measurements were made between Lightning Fork nodes only, and the defaults were sized for 483 slots: 8 tickets locked ahead with each seller. On a 30-slot channel, 8 tickets are more than a quarter of what everybody has, and three buyers with 8 each leave 6 slots for everyone else. Kyle Santiago, who read the design, pointed out both limits: this one, and the dust limit below. We then ran the XBT Core Lightning fork in the lab (see Numbers) and changed the defaults.

Two tickets, not eight

A session keeps 2 tickets locked and locks the next when 1 is left. A buyer that spends faster takes larger tickets, never more of them.

Never more than half

Held tickets take at most half the slots of a channel their holder can see, counting what is already pending there: the buyer on the channel its payments leave on, the seller on the channels it is paid over. That is 15 of 30. The other half stays free for ordinary payments and for everyone else. Where the number cannot be read, it is taken to be 30.

A full route means hold less

A lock that fails for lack of a slot cuts the session to one ticket and a wait. If one ticket will not lock either, the wallet stops holding tickets with that seller and pays another way: after a win in the lottery, or with a prepaid ticket that the seller collects as it arrives. Both are built.

A held ticket is never dust

Dust is the second limit. A locked payment smaller than a channel's dust limit is too small to get an output of its own in the channel's transaction: under 354 sat on a Lightning Fork node, under 546 sat on a Core Lightning node. Nobody can claim it on the chain, and it goes to the miners if the channel is force-closed while it is locked. In the lab, with tickets of 400, 600 and 1,000 sat held, a Core Lightning node's force close had outputs for the 600 and the 1,000 only. So a held ticket is at least 546 sat, the larger of the two limits, and the default stays 1,000. Anything smaller is paid at once and never held. That holds on channels of the anchor type, which both forks open by default. On a channel without anchors the limit rises with the fee rate, and so does the floor; see Fee rates.

Dust has a second cap

A node also limits the total of dust it will carry in one channel: 50,000 sat on Core Lightning. On a Core Lightning channel opened with 483 slots, 100 tickets of 500 sat locked and the next 30 were refused, and the buyer's node then found no route to that seller even for a 1,000 sat ticket. Tickets of 546 sat were all accepted.

These are the design's defaults as of this draft. The ticket book and the gateway in the public tree now have them. The tree's docs/LIMITS.md says what that means on a 30-slot channel.

Fee rates: what changes above 1 sat/vB

Every on-chain figure above was measured on regtest, at 1 sat/vB, on channels of the anchor type, and holds for that case only. Mainnet fee rates are often far higher, and many Lightning channels are of the older type without anchors. Two things change with the rate. On a channel without anchors, a pending payment has an output in the channel's transaction only if it is still above the dust limit after the fee of the transaction that would claim it, so the effective dust limit rises with the fee rate. And on any channel, every held ticket with an output adds 172 weight units to the transaction its funder pays for, and claiming a ticket on the chain costs its own fee. The table gives the default 1,000 sat ticket at three rates. It is computed from the transaction weights in BOLT 3, or scaled from the lab's 1 sat/vB figures where it says so. Nothing was run at 10 or 50 sat/vB, and no channel without anchors was run.

On an anchor channel an lnd-family node keeps the commitment transaction's own fee rate under a cap, 10 sat/vB by default as commonly documented (not checked in the fork's source), and whoever closes pays the rest, so the 50 sat/vB figures are in full a commitment fee only without anchors. What follows: a force close of a channel without anchors loses every ticket held on it that is below the threshold, not one; on any channel, an on-chain claim pays only in aggregate, where many tickets and the seller's whole balance share the cost of the close; and nobody on a route can see the type of a channel further along it, since it is not in gossip.

The floor for held tickets (built 17 October 2026). The default ticket stays 1,000 sat. Where a channel without anchors may be on the route, the wallet holds a ticket only if it is at least the larger of 546 sat and the dust limit plus the claim's fee at a fee-rate cap the owner sets. The cap is 10 sat/vB by default on mainnet and about 1 sat/vB on regtest and the test networks. On its own channels the wallet reads the type and the dust limit. Every channel past the first it takes to be without anchors, with a dust limit of 546 sat, because it cannot see them. So the floor through a routing node is 724 sat on regtest and 2,304 sat on mainnet at the defaults (computed), and a seller that is the wallet's direct peer has its channel's own floor. A ticket below the floor is not held: the wallet asks the seller for a larger size where its terms allow one, and otherwise pays the call by a prepaid ticket or the lottery. On mainnet, at the defaults, no ticket is held through a routing node, since the owner's largest ticket is 1,000 sat; those calls are paid with prepaid tickets or by the lottery. An owner who wants held tickets there raises the largest ticket to 2,304 sat or more, with a seller that offers that size. The gateway reads no dust limit and no channel type, and applies no floor of its own.

3The lottery in detail

The whitepaper has the idea and its figure; this is the rest. What the built form did in the lab is under Tests and numbers.

Why neither side can steer the roll

Each roll is made from two halves. The seller fixes its half of every roll before the session starts and shows only a fingerprint of them, so it cannot change one later. The buyer adds its half only after the piece has arrived, and for content it can check, only after the check passed. The two halves are hashed together and the result decides. When each side fixed its half it could not know the other's, and afterwards both can work out the result for themselves. Because the buyer's half comes after the piece, a seller cannot serve only the pieces that win. This argument treats the hash function, SHA-256, as a fair source of randomness. It is our own. Chris Guida's second review read it and the code that does it, and found no way for either side to steer a roll; that was one person's reading, not a proof and not an audit.

What it feels like

Uneven in the short run, exact in the long run. A miner knows the feeling: no block for a while, then one, and over a year the income matches the work. A seller's income from rolls evens out with the number of wins, and a seller chooses how often it wins by choosing the size of a win: wins in a day are the day's earnings divided by the win size. A buyer sees the same from the other side. One cheap download may cost a third more or a third less than its price, and over many downloads the average is the price. The costs, stated plainly has the figures.

How far "on average" reaches. The lottery is exact in expectation, and only in expectation. What one buyer pays one seller is a whole number of wins, and where n wins are expected the spread is about 1 over the square root of n. To be within 20% of the price nine times in ten takes about 68 wins between the same two parties, which is 4,350 sat at wins of 64 sat; to be within 5% takes about 1,080 wins, some 69,000 sat (computed). Below that it is luck. A call worth 10 sat, paid through a routing node where a win is 64 sat, expects a sixth of a win: about 85% of the time it pays nothing, and otherwise 64 sat or more. A session pools the calls of one buyer to one seller. Nothing pools across sellers or across buyers, and there is no bank, so more wins between the same two parties is the only thing that evens it out. For that reason, since 17 October 2026, the wallet keeps a call that expects fewer than 4 wins off the lottery where the seller also offers prepaid tickets, and pays it with a ticket: as shipped, that is every call that may use less than 256 sat through a routing node. Where the seller offers no prepaid tickets, such a call is paid by rolls as before. The owner can change the number of wins, or turn the rule off.

Two forms

The buyer pays after a win

Nothing is locked ahead. When a roll wins, the seller sends an ordinary Lightning invoice for the win, and the wallet, which has worked out the roll itself, pays it at once. This is simple, and it needs nothing but ordinary invoices. Its weakness is plain: a buyer can see a win and not pay. The seller serves on for a short while, then stops, and by then the cheat has had about one win's worth of service for free. Measured on a regtest lab, our own nodes, with pieces of a quarter of a sat and wins of 64 sat: a buyer that never paid was served 1.4 wins' worth on average before it was stopped (ten sessions, 3.3 wins' worth at the most in one; 0.8 to 1.4 on average over four runs). Where a seller would earn less than one win from a buyer in any case, a buyer that never pays gets everything for free. A buyer that sends no halves at all, or names every piece as lost (a void), is served the seller's window of 8 pieces in a session and no more: since 14 October 2026 a void counts against the window instead of making room in it, and the gateway ends a session after 4 voids. Before that, a buyer that voided every piece was served 24 pieces a session. Because the lottery is offered only for pieces of a quarter of a win or less, those 8 pieces are 2 wins' worth at the most, for each session a buyer is given; the gateway's caps on sessions, 64 in all and 4 from one address, bound how many. So this form is a cheap and exact way for honest buyers to pay tiny amounts, with a small, bounded loss to each cheat. It is not enforcement. Because nothing is held, neither a channel's slots nor its dust limit stands in the way: a win is in flight for about a quarter of a second, as any payment is. That makes this form the way to pay many sellers at once. The wallet paces the wins: at most 8 payments are on their way at a time, in the order the wins were found, except that a win a seller's answer is standing still for goes first.

A win that pays itself

The aim of this form, a win over Lightning that the loser cannot refuse to pay, was set out and first built by Paul Gerhart, Jay Taylor and Sri Aravinda Krishnan Thyagarajan in May 2026 [44]. What follows is our own way of reaching it, and it differs from theirs; see Prior art. The buyer first sets money aside in a locked box at the seller: an ordinary stream ticket, locked over Lightning, which only its key opens. Each roll then gives the seller a small chance of drawing the key, in a way that hides from the buyer whether it did. A seller that draws the key opens the box itself. The buyer cannot refuse to pay a win, because it learns of the win only when the money moves. After every roll, won or lost, the seller can check that the key really was there to be drawn. In our tests a buyer that offered rolls with no key in them was caught on half of those rolls, so a cheat gets about two pieces for free in place of a whole win's worth. The box is a held ticket, so it is at least 546 sat, and 1,000 by default. That makes this a form for a seller that earns several thousand sat from one buyer, not for a small one.

Where the two forms stand. The first form is built. It is in the wallet and in the seller's gateway in the public tree, and it runs on a regtest, on our own nodes. The gateway offers it beside tickets only where the dearest piece of a service is a quarter of a win or less, which is also the highest odds the wallet's owner allows by default, and the wallet chooses: tickets for a piece worth a ticket or more, for a seller it stays with and for a small call where prepaid tickets are offered, rolls for the rest and whenever it pays more sellers than tickets can be held with. A lottery session outlives a restart of the gateway: its rolls, its open pieces and its unpaid wins are kept in a journal on disk, written before a roll is revealed. The wallet's own side of a session does not outlive a restart of its signer; what it keeps on disk is every win's payment, written down before it is sent. The wallet works out every roll itself and pays only a win it found, so neither a seller nor an agent can talk it into paying a win that is not one. The argument that the roll is fair is still our own; one outside reviewer has read it and the code, and nobody has proved it. The second form is designed and was measured in a lab with a prototype. It is not built. It rests on an argument of our own, that a cheating buyer fails the seller's check on at least half of its rolls, which no cryptographer has reviewed; it will not be built until one has. On today's Lightning it also needs one proof for each locked payment, to show the seller that the box's lock and the rolls use the same key. We measured one such proof at a quarter of a second to make, and it needs a setup step that must not be trusted to one party.

What the second form is built from. None of its parts is ours. The roll uses oblivious transfer, in which a receiver takes one of two values and the sender does not learn which: the prototype uses the protocol of Chou and Orlandi [46], whose proof has since been questioned [47], extended to many transfers by the method of Ishai, Kilian, Nissim and Petrank [48]. That extension is safe only against a seller that follows the rules, so a real build needs a hardened one [49][50]. The transfers are combined by Gilboa's multiplication [51], the same step that threshold signing uses [52][53]. The proof that ties a lock to its rolls is a Groth16 proof [54] over the curve BLS12-381 [55] with the key on Jubjub [56], made with the arkworks libraries [57]; who may run its setup is the question studied in [58][59]. Only the way these are put together is ours, and that is the part nobody has reviewed.

4How it comes together

This is one session from the first request to the last, with a seller the buyer stays with and pieces smaller than a ticket, in the form where a win pays itself. That form is the design, and it is not built. In the form that is built, where the buyer pays after a win, two of the steps fall away: nothing is set aside and nothing is topped up, and a win is paid by an ordinary payment as soon as the wallet has found it.

Terms

A node runner puts a gateway in front of a service it already runs and sets a price for a piece. The gateway answers a first request with its terms: the price of a piece, the size of a win, and so the odds.

Limits

The wallet checks those terms against the owner's limits: the largest win, the highest odds, what any one seller may be paid, and the budget for the task. Terms outside the limits are refused before anything is paid.

Set aside

The wallet locks one payment with the seller over Lightning, of at least 546 sat as every held ticket is. Nothing has been spent. It is money set aside.

Roll

Each request carries the buyer's half of a roll. The roll rides on the request, so the service does not wait for it.

Win

When a roll wins, the seller collects the payment that was set aside. The wallet sees the money move on its own node, and books what its node paid, never a number the seller sends.

Top up

The wallet sets the next payment aside in the background, and the session goes on.

Stop

When the buyer stops, the seller cancels the payment that was set aside, and what was not won comes back, as an unused ticket does.

Which way of paying is used follows from the size of a piece and from how long the buyer stays with a seller. This is the rule the wallet has today.

If the win that pays itself is built one day, it would take the place of rolls with a seller the buyer stays with. Its win is a held ticket, so it would never be below 546 sat, and a seller that earns less than that from a buyer would still be paid after a win.

5Many sellers at once

Nothing in a ticket ties a buyer to one seller: each ticket is its own Lightning payment. But each held ticket takes a slot on every channel of its route, and the number that binds is the smallest over the whole route, shared by every buyer who uses it. From one channel of 30 slots, keeping to half of them, a buyer holds tickets with 7 sellers at two tickets each, or with 15 at one each. At 15 sellers with two each the channel is full and nothing else can pass through it. So on today's network held tickets are for one seller or a few.

Earlier drafts gave a much larger number of sellers that one channel could hold tickets with at once. That number is withdrawn. What the five-node lab behind it showed (a buyer, one routing node and three seller nodes, all Lightning Fork, every channel with 483 slots) is narrower: a Lightning Fork node accepts 483 pending payments on one channel, the most the protocol allows, and its router kept 400 tickets in flight at once, two each to 200 seller sessions spread over three nodes, locked in 11 seconds. It did not show a route that carries that many. A channel with a Core Lightning node at either end carries 30 at its default, as does eclair, and LDK carries 50, as commonly documented. The same lab showed that a seller that had just appeared could be paid a quarter of a second later through one routing node, and a tenth of a second later over a direct channel.

Many sellers at once are paid after a win in the lottery, which holds nothing. In the five-node lab, 200 seller sessions that all won in the same instant had all been paid 4.6 s later, with nothing held for any of them beforehand. On a 30-slot channel the wallet has to pace such payments: 200 payments of 64 sat all went through in 7.1 s when sent 8 at a time, and 139 of the 200 failed when sent 64 at a time.

Those were the design's measurements, made by scripts. The wallet and the gateway that are now built have done it too, on a regtest lab, our own nodes, through one routing node on channels of 30 slots. With 20 sellers paid at once, three small files from each: 3,840 rolls, 68 wins where 60 were expected, every file whole, no payment failed, 4.8 s. With 100 sellers: 19,200 rolls, 288 wins where 300 were expected, every file whole, no payment failed, 20 s, which is 14 wins a second. There were never more than 8 wins on the channel at once, and an ordinary payment of 5,000 sat that somebody else sent over the same channel meanwhile went through in half a second. One caution: the 100 sellers were 100 gateways beside one seller node. The channels carried what 100 sellers' wins would, and the seller's side was one node's worth of work. A second caution: those figures are from an idle machine. On a busy one the same check at first had a seller cut a file short, and the wallet's order of paying was changed for it; see A file cut short with 100 sellers.

Three limits remain, and each has an answer.

A ticket cannot be re-aimed

Once a Lightning payment is locked, its route and its receiver are sealed. Money cannot be locked first and pointed at a seller later, and a locked ticket cannot be moved to another seller. What can be done is to lock a new one, which is the quarter second above. The answer is not to wait for it: for content the buyer can check, the seller serves the first piece while the ticket locks, and paying after a win needs no lock at all. Serving a stranger one piece before it has paid is BitTorrent's "optimistic unchoke" [30], borrowed here.

Tickets are too coarse for small sellers

Through a routing node each collected payment costs about 1 sat, so paying one seller less than about 100 sat wastes more than 1%, below 1 sat nothing can be paid, and no ticket under 546 sat is held. In a swarm most sellers earn far less than that. The answer is the lottery.

Held tickets are a shared, limited resource

A channel carries between 30 and 483 held payments in each direction, for all sellers and every other user together, and the wallet takes at most half: 15 on a 30-slot channel. A seller that leaves without cancelling keeps its tickets locked for hours, and in a swarm sellers leave all the time. The answer is to hold little: two tickets with a seller the buyer stays with, one with a seller the owner has not named, one each when there are a few, one where a win pays itself, and none where the buyer pays after a win, which is how a swarm is paid.

An owner cannot list sellers it has never heard of. In place of a list of names it approves a kind of spending: a budget for the task, and a small cap on what any one unknown seller can be paid. The wallet has that part of the policy, for tickets and for wins. A seller the owner has not named is paid wins of 250 sat at the most, and no more than 32 wins in a task's window; with tickets, it is paid one prepaid ticket first and then held with one ticket at a time (A seller the owner has not named).

6The costs, stated plainly

The spreads below are simulations, except where a line says it was measured. "Nine days in ten" means the middle nine tenths of the days simulated.

Uneven income for a seller

A seller that earns about 4,000 sat a day in pieces of a tenth of a sat, with wins of 64 sat, is paid between 80% and 120% of what it earned nine days in ten, and between 96% and 104% over a month. A seller that earns 1,000 sat a day sees 58% to 141% on a day and 92% to 108% over a month. A seller that earns 100 sat a day gets no win at all one day in five. The rule behind these figures is the horizon above: about 68 wins for 20%, about 1,080 for 5% (How far "on average" reaches).

The seller chooses the trade

A smaller win means steadier income and a larger share lost to routing fees, because each win costs about 1 sat for each routing node it passes: 6.25% of a 16 sat win, 1.6% of 64, 0.4% of 250, 0.1% of 1,000. A node that runs several services gets steadier income for nothing, because all their wins land on one node: twenty services that each earn 1,000 sat a day bring that node within 9% of its earnings on a day.

Uneven cost for a buyer

A download priced at 1,638 sat (4 GiB at a tenth of a sat a piece, wins of 64 sat) cost between 1,152 and 2,176 sat nine times in ten. For it not to stall on an unlucky run more than once in a thousand, the owner must allow 2,795 sat, fees included. The budget is a ceiling. The average stays at the price. Measured on a regtest lab, our own nodes: a file priced at 381.5 sat, bought five times, cost 520, 780, 390, 260 and 325 sat with routing fees. The wallet stops asking for more pieces when the wins of one call run far above its price (for a call of 1,000 sat on wins of 64 sat, at 1,848 sat), and the budget the owner gave the task holds whatever the rolls do.

The seller goes first when the buyer pays after a win

By about one win's worth for each new buyer, and by everything where a seller earns less than one win from a buyer. Measured on a regtest lab, our own nodes: a buyer that never paid was served 1.4 wins' worth on average with pieces of a quarter of a sat, and 3.9 wins' worth with pieces of a quarter of a win, because the gateway bears two unpaid wins and serves 8 pieces ahead. A buyer that sends no halves at all, or voids every piece, gets the window of 8 pieces a session, which is 2 wins' worth at most, since no piece dearer than a quarter of a win is drawn for. Behind a reverse proxy the gateway's cap on sessions from one address counts only if the runner names the proxy and the header it reports a buyer's address in; otherwise every buyer has the proxy's address. Nothing on today's Lightning can force a buyer to pay a seller it touched only briefly.

What routing nodes carry

Tickets are held payments, and a win that pays itself needs one held for each seller. Each takes a slot on every channel of its route for as long as it is held. A routing node is paid nothing for one that is cancelled. If a seller vanishes with tickets locked, the routing node that opened the channel to it bears a forced close: with 100 tickets of 1,000 sat locked that cost about 29,000 sat in all at 1 sat/vB, which is 29% of the tickets' value, and with 3 tickets 1,530 sat (measured on regtest, anchor channels); scaled to 10 sat/vB the first is about 290,000 sat (Fee rates). A locked payment below a channel's dust limit, 354 sat on a Lightning Fork node and 546 sat on a Core Lightning node, cannot be claimed on the chain at all, which is why no ticket under 546 sat is held. Paying after a win holds nothing, and pays the routing node for every payment it carries.

A win that pays itself cannot be small

Its win is a held ticket, so it is at least 546 sat. Larger wins mean lumpier income: over a month, a seller that earns about 4,000 sat a day is paid between 85% and 115% of it with wins of 1,000 sat, against 96% to 104% with wins of 64 sat (simulated). A small seller is better paid after a win, where a win can be any size.

Pooling does not work here

Miners even out their income in pools, and Meni Rosenfeld's analysis of how pools pay [45] is where we took the comparison from. Pooling does not carry over, because a mining share is proof of work that anyone can check, and a piece served proves nothing to anyone who was not there: a seller and a friendly buyer could invent pieces and draw on the pool for free.

The deeper help is in Lightning itself

Changes to Lightning would do more than anything we can add on top of it. Point locks [14][15] first: with them the self-paying win would no longer need its proof. Then a fee for held payments [11][12], which would pay routing nodes for what tickets ask of them. Both are proposals made by others for Lightning as a whole. Neither exists on the XBT Lightning forks. They are other people's software. We can ask for them, and we cannot promise them.

7Prior art

Nothing in a ticket is a new mechanism. It is the hold invoice Lightning nodes already have [5], used to the end that "stuckless payments" were proposed for in 2019 [6], and bound to HTTP 402 and to an agent's spending policy. The numbers in square brackets point to References. The policy wallet is the part we think is most useful.

L402

Lightning Labs' HTTP 402 binding [23]: a macaroon plus a Lightning invoice. Used for metered services it becomes a prepaid balance at the seller. A seller that collects each ticket on arrival, before it is used, is running exactly that in ticket-sized units, and a seller whose node has no hold invoices can do so.

Keysend streaming

Podcast apps stream sats for each minute listened, usually as one spontaneous Lightning payment a minute [8][9]. That is a payment per piece: it suits a service where a wait of a tenth of a second or more per piece does not matter. AMP [7] is the other spontaneous payment Lightning has; in neither does the payer hold anything back, so neither is a ticket.

x402

The HTTP payment standard whose shape Lightning Stream uses [22]. Its batch-settlement scheme, where the client commits at request time and value settles later, is the name the earlier channel was carried under before it was removed. The ticket and lottery entries are our own, and the upstream clients do not speak them.

Nostr Wallet Connect

NIP-47 [25] gives each app its own connection to a wallet, which the owner can limit or revoke, and wallets that speak it put spending budgets on those connections. The policy wallet applies the same idea to agents, with an owner-signed policy.

Routstr and Cashu

Inference paid for request by request with Cashu ecash [27][28]. Payments are instant and private, but the mint holds the money. A locked ticket is held by nobody: it sits in Lightning channels until the buyer releases it or it returns.

Ark

One operator serving many recipients off chain [29], the shape the retired hub had. Users can exit on chain alone at any time before their coins expire, and must come back before then to refresh them. Lightning Stream now has no operator of its own.

Paying by lottery

Paying small amounts by lottery is an old idea, and none of it is ours. David Wheeler proposed "transactions using bets" in 1996 [33], and Ronald Rivest described "Electronic Lottery Tickets as Micropayments" in 1997 [34], with a bank that honours the winning tickets; Rivest's paper names still earlier forms of the idea. Silvio Micali and Rivest removed the back-and-forth in 2002 [35]. Rafael Pass and abhi shelat put an escrow on a chain in the bank's place in 2015 [36], in one form with no third party and in two with a third party whose conduct anyone can check. Orchid [39] and Livepeer [40] run such lotteries with a contract that holds the payer's deposit and pays a winner without the payer's help. Chiesa and others added privacy and defined a transfer that succeeds with a set probability [37], which Mitani and Otsuka built for payment hubs [38]. For Bitcoin itself the idea was raised by Mike Caldwell in 2012 [41], sketched inside Lightning channels by Tadge Dryja in 2016 [42], and built from specially made keys by Oleksandr Kurbatov in 2025 [43]. Lightning has neither a bank nor such a contract, and that is why the plain form here leaves the seller exposed by about one win. The plain form adds nothing to these but the binding to a request and to an owner's policy.

In May 2026 Paul Gerhart, Jay Taylor and Sri Aravinda Krishnan Thyagarajan published "Probabilistic Atomic Swaps for Bitcoin and Friends" (arXiv:2605.04975) [44], which builds an exchange that completes with a set probability and enforces itself, runs it between two test networks, and shows it over Lightning with a prototype of two nodes. The aim of a win that enforces itself off the chain is theirs first, and so is the proof that ties a hash lock to a key, which we measured after them. As we read their paper, each of their rolls is a small paid exchange of its own, where ours keeps one payment locked and lets the roll ride on a request the buyer sends anyway; theirs is built from adaptor signatures and an oblivious pseudorandom function, where ours uses oblivious transfer; and theirs comes with a formal treatment, where the check ours depends on is our own argument and has not been reviewed. Where the two differ, theirs is the one that has been set down properly.

Where tickets sit

Tickets sit between a prepaid balance and a payment per piece. A prepaid balance hands the seller the money before the service. A payment per piece hands it over piece by piece and makes each piece wait. A ticket commits the money before the service and hands it over a ticket at a time, inside the request.

The timings and fees in this table were measured on a three-node regtest lab, one hop. A seller's 402 can list more than one of the three.

8References

Each of these was opened and read against what this paper says of it on 12 October 2026. Where we could only read an archived copy, or only part of a source, the entry says so.

Payment channels and Lightning

1. J. Spilman. "Anti DoS for tx replacement". bitcoin-development mailing list, 20 April 2013. archived copy.
2. P. Todd. "BIP 65: OP_CHECKLOCKTIMEVERIFY". 2014. Its section "Payment Channels" describes "Jeremy Spilman style payment channels". bip-0065.
3. J. Poon, T. Dryja. "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments". Draft 0.5.9.2, 14 January 2016. lightning.network.
4. Lightning Network developers. "BOLT: Basis of Lightning Technology". BOLT 2 (the peer protocol: the most pending payments a node may accept in a channel, 483, and the cap a node may put on dust), BOLT 3 (which pending payments get an output in a channel's transaction), BOLT 11 (invoices), BOLT 12 (offers; R. Russell, merged 2024). lightning/bolts.
5. J. Jager. "htlcswitch: hodl invoice". lnd pull request 2022, merged March 2019; released in lnd v0.6-beta, April 2019. The calls are AddHoldInvoice, SettleInvoice and CancelInvoice of lnd's invoices service. pull request, Optech: hold invoices.
6. H. Gondo. "Proposal for Stuckless Payment". lightning-dev mailing list, 25 June 2019. archived copy.
7. O. Osuntokun, with C. Fromknecht. "AMP: Atomic Multi-Path Payments over Lightning". lightning-dev mailing list, 6 February 2018. archived copy.
8. V. Wallace. "bLIP 3: Keysend". 2021. blip-0003.
9. Satoshis Stream. "bLIP 10: Podcasting 2.0 Streaming payments, Boosts and Boostagrams". 2022. blip-0010.
10. Bitcoin Optech. "Channel jamming attacks". Topic page. bitcoinops.org.
11. C. Shikhelman, S. Tikhomirov. "Unjamming Lightning: A Systematic Approach". Cryptology ePrint Archive 2022/1454, 2022. ePrint 2022/1454.
12. J. Jager. "Hold fee rates as DoS protection (channel spamming and jamming)". lightning-dev mailing list, 11 February 2021. archived copy.
13. C. Kirk-Cohen. "bLIP 4: Experimental Endorsement Signaling". 2024. blip-0004, Optech: HTLC endorsement.
14. Bitcoin Optech. "Point Time Locked Contracts (PTLCs)". Topic page. See also "Multi-Hop Locks from Scriptless Scripts", Blockstream Research. bitcoinops.org, multi-hop locks.
15. G. Malavolta, P. Moreno-Sanchez, C. Schneidewind, A. Kate, M. Maffei. "Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability". NDSS 2019. ePrint 2018/472.
16. A. Poelstra. "Scriptless Scripts". Slides, MIT Bitcoin Expo, 4 March 2017. slides.
17. L. Aumayr, O. Ersoy, A. Erwig, S. Faust, K. Hostakova, M. Maffei, P. Moreno-Sanchez, S. Riahi. "Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures". Asiacrypt 2021. ePrint 2020/476.
18. Blockstream Research. libsecp256k1-zkp, module ecdsa_adaptor, which follows L. Fournier, "One-Time Verifiably Encrypted Signatures A.K.A. Adaptor Signatures". secp256k1-zkp. We read the module's header, which names Fournier's paper; we did not read the paper itself.
19. E. Heilman, L. AlShenibr, F. Baldimtsi, A. Scafuro, S. Goldberg. "TumbleBit: An Untrusted Bitcoin-Compatible Anonymous Payment Hub". NDSS 2017. ePrint 2016/575.
20. E. Tairi, P. Moreno-Sanchez, M. Maffei. "A2L: Anonymous Atomic Locks for Scalability in Payment Channel Hubs". IEEE Symposium on Security and Privacy 2021. ePrint 2019/589.

HTTP, agents and other payment systems

21. R. Fielding and others. "Hypertext Transfer Protocol: HTTP/1.1". RFC 2068, January 1997, section 10.4.3: "402 Payment Required. This code is reserved for future use." It is still reserved in RFC 9110 (2022), section 15.5.3. RFC 2068, RFC 9110.
22. x402 Foundation. "x402", protocol version 2, with its schemes exact (and exact on Lightning, 2026), upto and batch-settlement. Created by Coinbase; since April 2026 kept by the x402 Foundation under the Linux Foundation. Apache-2.0. x402-foundation/x402, announcement.
23. Lightning Labs. "L402 Protocol Specification". lightninglabs/L402.
24. S. Warta, ligi, P. Gomes, A. Herzog. "CAIP-2: Blockchain ID Specification". 2019. With the bip122 namespace (Warta, ligi, Gomes), which follows M. Pontello, "BIP 122: URI scheme for Blockchain references / exploration". CAIP-2, bip122 namespace.
25. Nostr contributors. "NIP-47: Nostr Wallet Connect". 2023. NIP-47.
26. Anthropic. "Introducing the Model Context Protocol". 25 November 2024. Since December 2025 the protocol is kept by the Agentic AI Foundation, under the Linux Foundation. announcement, modelcontextprotocol.io.
27. Cashu contributors (calle and others). "Cashu NUTs", the Cashu protocol specifications; "NUT-24: HTTP 402 Payment Required". cashubtc/nuts, NUT-24.
28. Routstr. "routstr-core". Routstr/routstr-core.
29. Burak. "Ark: An Alternative Privacy-preserving Second Layer Solution". bitcoin-dev mailing list, 22 May 2023. For expiry and refresh as built: Second, "VTXO lifetime". archived copy, second.tech.
30. B. Cohen. "Incentives Build Robustness in BitTorrent". 22 May 2003. Section 3.3, "Optimistic Unchoking". bittorrent.org.
31. G. Maxwell. "Zero Knowledge Contingent Payment". Bitcoin Wiki, page created 28 November 2011. Bitcoin Wiki. The page names no author in its text; the author and date are from its history.
32. R. C. Merkle. "A Digital Signature Based on a Conventional Encryption Function". Crypto '87, Springer, 1988. doi:10.1007/3-540-48184-2_32.

Paying by lottery

33. D. Wheeler. "Transactions Using Bets". Security Protocols, LNCS 1189, Springer, 1996. doi:10.1007/3-540-62494-5_7. We read its record and what Rivest and later authors say of it, not the paper itself.
34. R. L. Rivest. "Electronic Lottery Tickets as Micropayments". Financial Cryptography 1997. author's copy.
35. S. Micali, R. L. Rivest. "Micropayments Revisited". CT-RSA 2002. author's copy.
36. R. Pass, a. shelat. "Micropayments for Decentralized Currencies". ACM CCS 2015. ePrint 2016/332.
37. A. Chiesa, M. Green, J. Liu, P. Miao, I. Miers, P. Mishra. "Decentralized Anonymous Micropayments". Eurocrypt 2017. ePrint 2016/1033.
38. T. Mitani, A. Otsuka. "Anonymous probabilistic payment in payment hub". Cryptology ePrint Archive 2020/748, 2020 (a preprint). ePrint 2020/748.
39. J. S. Cannell, J. Sheek, J. Freeman, G. Hazel, J. Rodriguez-Mueller, E. Hou, B. J. Fox, S. Waterhouse. "Orchid: A Decentralized Network Routing Market". Version 2.0, 2019. whitepaper.
40. D. Petkanics, Y. Fu. "Livepeer Streamflow Paper". 2018. The contract is TicketBroker in the Livepeer protocol. Streamflow, contract.
41. M. Caldwell (casascius). "Sustainable nanopayment idea: Probabilistic Payments". Bitcoin Forum, 4 February 2012. bitcointalk.org.
42. T. Dryja. "LN as a Directed Graph: Single-Funded Channel Topology". Slides, 11 April 2016. slides.
43. O. Kurbatov. "Emulating OP_RAND in Bitcoin". arXiv:2501.16451, January 2025, and the Delving Bitcoin thread "Emulating OP_RAND". arXiv:2501.16451, thread, Optech: probabilistic payments.
44. P. Gerhart, J. Taylor, S. A. K. Thyagarajan. "Probabilistic Atomic Swaps for Bitcoin and Friends". arXiv:2605.04975, 6 May 2026. arXiv:2605.04975.
45. M. Rosenfeld. "Analysis of Bitcoin Pooled Mining Reward Systems". arXiv:1112.4980, 2011. arXiv:1112.4980.

Building blocks of the sealed draw

46. T. Chou, C. Orlandi. "The Simplest Protocol for Oblivious Transfer". Latincrypt 2015. ePrint 2015/267.
47. Z. A. Genç, V. Iovino, A. Rial. "'The Simplest Protocol for Oblivious Transfer' Revisited". Information Processing Letters, 2020. It finds a flaw in the security proof of the protocol above. ePrint 2017/370.
48. Y. Ishai, J. Kilian, K. Nissim, E. Petrank. "Extending Oblivious Transfers Efficiently". Crypto 2003. doi:10.1007/978-3-540-45146-4_9.
49. M. Keller, E. Orsini, P. Scholl. "Actively Secure OT Extension with Optimal Overhead". Crypto 2015, revised 2022. The authors' 2022 note says the original proof does not hold and gives a repair that uses Roy's technique. ePrint 2015/546.
50. L. Roy. "SoftSpokenOT: Quieter OT Extension From Small-Field Silent VOLE in the Minicrypt Model". Crypto 2022. ePrint 2022/192.
51. N. Gilboa. "Two Party RSA Key Generation". Crypto '99. doi:10.1007/3-540-48405-1_8.
52. J. Doerner, Y. Kondi, E. Lee, a. shelat. "Secure Two-party Threshold ECDSA from ECDSA Assumptions". IEEE Symposium on Security and Privacy 2018. ePrint 2018/499.
53. J. Doerner, Y. Kondi, E. Lee, a. shelat. "Threshold ECDSA in Three Rounds". IEEE Symposium on Security and Privacy 2024. ePrint 2023/765.
54. J. Groth. "On the Size of Pairing-based Non-interactive Arguments". Eurocrypt 2016. ePrint 2016/260.
55. Electric Coin Company. "BLS12-381: New zk-SNARK Elliptic Curve Construction". 11 March 2017. blog post.
56. D.-E. Hopwood, S. Bowe, T. Hornby, N. Wilcox. "Zcash Protocol Specification". Section 5.4.9.3, "Jubjub". zips.z.cash. Read from an archived copy of 21 September 2026; the address given did not answer us.
57. arkworks contributors. ark-groth16, ark-bls12-381 and ark-ed-on-bls12-381, Rust libraries. MIT or Apache-2.0. arkworks-rs.
58. M. Campanelli, R. Gennaro, S. Goldfeder, L. Nizzardo. "Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services". ACM CCS 2017. ePrint 2017/566.
59. G. Fuchsbauer. "Subversion-zero-knowledge SNARKs". PKC 2018. ePrint 2017/587.

Software this work runs on

60. Bitcoin Knots, maintained by Luke Dashjr. Release 29.4.1 (September 2026) carries the BLAKE2b proof of work (L. Dashjr) and the unified opt-in signature hash (K. Santiago; specified in the tree's doc/unified-sighash.md), activated at block 961,640 together with the reduced-data rules of BIP 110 (D. Ohm). MIT. bitcoinknots/bitcoin, unified-sighash.md.
61. Lightning Fork, by Paul Lamb: lnd for the BLAKE2b chain. Measured here at tag v0.21.3-beta-blake2b.17 (commit cebc10fe), in the regtest lab of the same author, lightning-fork-lab, at commit a5cadc5. Lightning Fork is MIT; the lab carries no licence file. paulscode/lightning-fork, paulscode/lightning-fork-lab.
62. lnd, the Lightning Network Daemon, by Lightning Labs and the Lightning Network developers. MIT. lightningnetwork/lnd.
63. The Core Lightning fork for the BLAKE2b chain, by PrivKey, built on Core Lightning (R. Russell, Blockstream, and contributors). Measured here at release v26.06.9-blake2b.7 (commit 482c8c52), from the released binaries, as buyer, routing node and seller. Its documentation at that tag (doc/lightningd-config.5.md) gives the default of 30 pending payments in each direction of a channel. privkeyio/lightning, release, ElementsProject/lightning.
64. electrs, by Roman Zeyde. MIT. romanz/electrs.
65. libsecp256k1, by Pieter Wuille and the Bitcoin Core developers. MIT. bitcoin-core/secp256k1.
66. OCEAN. DATUM Gateway (Bitcoin Ocean, LLC, Jason Hughes and contributors; MIT), and J. Hughes, "TIDES: Transparent Index of Distinct Extended Shares", 2024. OCEAN-xyz/datum_gateway, TIDES.
67. Core Lightning documentation. "htlc_accepted", the plugin hook through which a plugin can fail an incoming payment, let it continue, or settle it with a secret. docs.corelightning.org.
68. Boltz. "hold", a hold invoice plugin for Core Lightning. MIT. Tried at v0.3.3. BoltzExchange/hold. We loaded it on the fork and asked it for one invoice, which lacked the XBT feature bit, so a Lightning Fork node refused to pay it; we tried nothing more.
69. daywalker90. "holdinvoice", a hold invoice plugin for Core Lightning. MIT. Read at v4.0.0. daywalker90/holdinvoice. Not run by us. By its README it settles an invoice by its hash, so the secret is the seller's; the repository is archived and points to the plugin above.

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