Rusty Russell

Large projects often start quietly. Blockstream’s retrospective of 9 June 2026 recalls Russell’s first commit on 26 May 2015: a small tool for constructing a message to open a channel. A commit is a recorded change in a codebase’s history. That early experiment grew into Core Lightning, with Russell contributing to its software, tests and the development of other engineers. The article also describes his departure after eleven years. It does not announce the end of all future open-source contributions or turn a former leadership role into permanent authority over the network. [1]

Imagine a café and a customer using different programs. Payment should not depend on choosing the same software provider. They need shared rules for messages and their meaning. The BOLT specifications describe this communication in Lightning. Russell chaired their collaborative development process and supported interoperability, the ability of different implementations to work together. The public repository accepts proposals and comments. Even a prominent contributor cannot impose a change on every node alone: shared rules must become part of real software and actual use. [1] [2]

Two programs can interpret the same paragraph differently. Russell’s lnprototest provides helpers written in Python for creating scenarios and testing responses to protocol messages. Its README, the project’s introductory documentation, distinguishes a dummy runner from testing against a real implementation. A simulation helps prepare a test, but simulation success alone does not prove how a real node behaves. We need to know what actually ran and which situations were covered. Even a passing set of scenarios is not a complete audit of every possible defect. [3]

Under BOLT 12, a café can publish a reusable offer, perhaps as a QR code. A customer’s wallet uses it to send an invoice_request and receive a specific invoice: a payment request containing the details for that payment. Payment comes afterwards. Customers can therefore reuse the offer while receiving individual invoices. This does not mean presenting one previously used invoice as a fresh request for every purchase. Separating the offer, the request and the invoice makes payment convenient without confusing separate purchases. [4]

Core Lightning makes this separation visible. Its fetchinvoice command contacts the offer issuer and retrieves an invoice. The changes field can report differences from the offer, such as the description or amount. A successful response does not send money. It is like receiving a café bill: first check what you are paying for and how much. The wallet must process the returned terms and initiate payment separately. Completing the retrieval of a request must not be mistaken for completing its payment. [5]

The pay interface documentation distinguishes complete, pending and failed. Pending is not success. It also separates amount_msat, the amount received by the recipient, from amount_sent_msat, the total sent including fees. The msat abbreviation means millisatoshi, one thousandth of a satoshi. A customer may therefore spend a fee more than the café receives. The documentation now marks pay as deprecated and describes the transition to xpay; this explains states and amounts rather than instructing readers to install a particular version. Interpret results using the software actually in use. [6]

When the café refunds money, the original payment is not rewound. BOLT 12 also describes the reverse flow: the merchant announces an amount it wants to send, the customer supplies an invoice, and the merchant checks invoice_node_id, the identifier of the node it intends to pay. A new payment then travels to the customer. This neither cancels the original transfer nor automatically creates an entitlement to a refund. The protocol provides a way to carry it out; the reason and terms must be settled separately by the participants. [4]

In a dispute, it helps to understand exactly what a proof establishes. BOLT 12 explains that a preimage, the secret value matching the hash in a payment request, can demonstrate that an invoice was paid. Once revealed, however, someone else can show it too; it does not identify who sent the money. A key included in the request can prove who requested the invoice. This does not automatically verify civil identity. A paid invoice, control of a key and a customer’s real-world identity are separate facts, even when everyday language blends them together. [4]