mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2026-11-08 10:25:32 +01:00
Code Issues Projects Releases Packages Wiki Activity
A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
12,298 commits 30 branches 93 tags 70 MiB
  • Rust 99.4%
  • Shell 0.3%
  • RenderScript 0.2%
Find a file
Exact
Matt Corallo 5653142a0e Merge PR 'Include recovery ID in invoice signature ordering' (#5516) 
from tankyleo/leo/ord-bolt11invoicesignature into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/5516
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
2026-11-06 21:46:55 +00:00
.forgejo Merge PR 'Use the Forgejo REST API directly in the CI failure-issue job' (#5224) 2026-10-27 14:49:35 +00:00
.github/workflows Apply MSRV dependency pins in the tor-connect CI job 2026-10-20 11:32:34 -04:00
bench prefactor: move FilesystemStore utilies into fs_store/common.rs 2026-02-19 12:31:09 -06:00
ci Pin backtrace to 0.3.76 for rustc 1.82 through 1.87 2026-10-27 13:19:08 +00:00
contrib Manually cache downloaded artifacts in forgejo actions 2026-08-12 21:52:42 +00:00
ext-functional-test-demo Add methods to fetch an OfferBuilder for "phantom" node configs 2026-02-11 15:30:00 +00:00
fuzz Revert "Pass entropy source when queueing monitor event" 2026-10-05 10:41:41 -04:00
lightning Merge PR 'Count pending UTXO lookup states toward gossip backpressure' (#5511) 2026-11-06 04:14:25 +00:00
lightning-background-processor Merge PR 'Only prune the network graph after a fresh RGS sync' (#5000) 2026-10-20 20:01:12 +00:00
lightning-block-sync Preserve ancestor history in reorg disconnect locators 2026-10-09 12:37:22 +00:00
lightning-custom-message Test composite peer_connected short-circuits at first rejection 2026-10-29 08:56:15 +00:00
lightning-dns-resolver Add logger to KeysManager and InMemorySigner 2026-09-02 19:26:49 +00:00
lightning-invoice Merge PR 'Include recovery ID in invoice signature ordering' (#5516) 2026-11-06 21:46:55 +00:00
lightning-liquidity Persist LSPS2 deferred funding transaction and broadcast authorization 2026-11-03 06:59:56 +00:00
lightning-macros Support retired TLV fields in object-constructing macros 2026-08-31 15:24:27 -05:00
lightning-net-tokio Propagate fatal write errors when socket reads are paused 2026-10-11 08:04:11 +00:00
lightning-payer-proof offers: rename matches_invoice_signing_pubkey to key_can_sign_invoice 2026-08-31 18:19:43 +02:00
lightning-persister Merge PR 'Propagate namespace lookup errors in fs_store listing' (#5270) 2026-10-28 01:12:03 +00:00
lightning-rapid-gossip-sync Finish RGS snapshot processing when there are no channel updates 2026-09-21 15:38:49 +00:00
lightning-tests Abandon claims of irrevocably spent HTLC outputs 2026-11-05 21:17:46 +00:00
lightning-transaction-sync tx-sync: parallelize esplora status queries 2026-09-14 17:18:20 -07:00
lightning-types Use feature bits 80/81 for option_simple_taproot 2026-10-09 13:37:47 -04:00
msrv-no-dev-deps-check lightning-payer-proof: add a verification-only crate 2026-08-19 20:04:58 +02:00
no-std-check lightning-payer-proof: add a verification-only crate 2026-08-19 20:04:58 +02:00
pending_changelog Bound the length of built and signed invoices 2026-10-22 16:44:56 -05:00
possiblyrandom Update crate repository links to forgejo 2026-08-03 03:01:39 -05:00
.editorconfig Introduce graph sync crate for fast-forwarding through gossip data downloaded from a server. 2022-05-25 01:21:33 -07:00
.gitignore lightning-payer-proof: add uniffi bindings 2026-08-19 20:04:58 +02:00
AGENTS.md Add AGENTS.md symlink 2026-06-01 13:53:26 -05:00
ARCH.md arch: update diagram to reflect changes to KeysInterface 2024-10-08 10:35:14 -04:00
Cargo.toml lightning-payer-proof: add a verification-only crate 2026-08-19 20:04:58 +02:00
CHANGELOG.md Add 0.2.7 and 0.1.13 changelogs 2026-10-02 18:56:02 +00:00
CLAUDE.md Document Forgejo access for agents 2026-10-28 20:59:43 +00:00
codecov.yml Ignore patch codecov as long as total coverage is within 1% of base 2021-03-19 20:49:14 -04:00
CONTRIBUTING.md Bump the CI rustfmt task to 1.85 2026-10-17 15:00:57 +00:00
GLOSSARY.md Add a GLOSSARY.md 2021-01-18 11:05:57 -05:00
LICENSE-APACHE Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
LICENSE-MIT Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
LICENSE.md Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
README.md Drop no-std feature 2024-09-18 09:07:58 +02:00
REVIEWERS.md Add additional REVIEWERS.md context for security scanners 2026-10-12 22:06:58 +00:00
rustfmt.toml Bump MSRV to rustc 1.75.0 2025-10-22 16:14:28 -05:00
SECURITY.md Drop Arik from SECURITY.md 2026-03-17 20:04:43 +00:00

README.md

Rust-Lightning

Crate Documentation Safety Dance Security Audit

LDK/rust-lightning is a highly performant and flexible implementation of the Lightning Network protocol.

The primary crate, lightning, is runtime-agnostic. Data persistence, chain interactions, and networking can be provided by LDK's sample modules, or you may provide your own custom implementations. More information is available in the About section.

Status

The project implements all of the BOLT specifications, and has been in production use since 2021. As with any Lightning implementation, care and attention to detail is important for safe deployment.

Communications for rust-lightning and Lightning Development Kit happen through our LDK Discord channels.

Crates

  1. lightning The core of the LDK library, implements the Lightning protocol, channel state machine, and on-chain logic. Supports no_std and exposes only relatively low-level interfaces.
  2. lightning-background-processor Utilities to perform required background tasks for Rust Lightning.
  3. lightning-block-sync Utilities to fetch the chain data from a block source and feed them into Rust Lightning.
  4. lightning-invoice Data structures to parse and serialize BOLT #11 Lightning invoices.
  5. lightning-net-tokio Implementation of the rust-lightning network stack using the Tokio async runtime. For rust-lightning clients which wish to make direct connections to Lightning P2P nodes, this is a simple alternative to implementing the required network stack, especially for those already using Tokio.
  6. lightning-persister Implements utilities to manage rust-lightning channel data persistence and retrieval. Persisting channel data is crucial to avoiding loss of channel funds.
  7. lightning-rapid-gossip-sync Client for rapid gossip graph syncing, aimed primarily at mobile clients.

About

LDK/rust-lightning is a generic library that allows you to build a Lightning node without needing to worry about getting all of the Lightning state machine, routing, and on-chain punishment code (and other chain interactions) exactly correct. Note that LDK isn't, in itself, a node. For an out-of-the-box Lightning node based on LDK, see LDK-sample. However, if you want to integrate Lightning with custom features such as your own chain sync, key management, data storage/backup logic, etc., LDK is likely your best option. Some rust-lightning utilities such as those in chan_utils are also suitable for use in non-LN Bitcoin applications such as Discreet Log Contracts (DLCs) and bulletin boards.

Also check out LDK-node library if you want to easily integrate lightning in your application without taking care of all the boiler plate code.

In general, rust-lightning does not provide (but LDK has implementations of):

  • on-disk storage - you can store the channel state any way you want - whether Google Drive/iCloud, a local disk, any key-value store/database/a remote server, or any combination of them - we provide a clean API that provides objects which can be serialized into simple binary blobs, and stored in any way you wish.
  • blockchain data - we provide a simple block_connected/block_disconnected API which you provide block headers and transaction information to. We also provide an API for getting information about transactions we wish to be informed of, which is compatible with Electrum server requests/neutrino filtering/etc.
  • UTXO management - RL/LDK owns on-chain funds as long as they are claimable as part of a Lightning output which can be contested - once a channel is closed and all on-chain outputs are spendable only by the user, we provide users notifications that a UTXO is "theirs" again and it is up to them to spend it as they wish. Additionally, channel funding is accomplished with a generic API which notifies users of the output which needs to appear on-chain, which they can then create a transaction for. Once a transaction is created, we handle the rest. This is a large part of our API's goals - making it easier to integrate Lightning into existing on-chain wallets which have their own on-chain logic - without needing to move funds in and out of a separate Lightning wallet with on-chain transactions and a separate private key system.
  • networking - to enable a user to run a full Lightning node on an embedded machine, we don't specify exactly how to connect to another node at all! We provide a default implementation which uses TCP sockets, but, e.g., if you wanted to run your full Lightning node on a hardware wallet, you could, by piping the Lightning network messages over USB/serial and then sending them in a TCP socket from another machine.
  • private keys - again we have "default implementations", but users can choose to provide private keys to RL/LDK in any way they wish following a simple API. We even support a generic API for signing transactions, allowing users to run RL/LDK without any private keys in memory/putting private keys only on hardware wallets.

LDK's customizability was presented about at Advancing Bitcoin in February 2020: https://vimeo.com/showcase/8372504/video/412818125

Design Goal

The goal is to provide a fully-featured and incredibly flexible Lightning implementation, allowing users to decide how they wish to use it. With that in mind, everything should be exposed via simple, composable APIs. More information about rust-lightning's flexibility is provided in the About section above.

For security reasons, do not add new dependencies. Really do not add new non-optional/non-test/non-library dependencies. Really really do not add dependencies with dependencies. Do convince Andrew to cut down dependency usage in rust-bitcoin.

Rust-Lightning vs. LDK (Lightning Development Kit)

rust-lightning refers to the core lightning crate within this repo, whereas LDK encompasses rust-lightning and all of its sample modules and crates (e.g. the lightning-persister crate), language bindings, sample node implementation(s), and other tools built around using rust-lightning for Lightning integration or building a Lightning node.

Tagline

"Rust-Lightning, not Rusty's Lightning!"

Contributing

Contributors are warmly welcome, see CONTRIBUTING.md.

Project Architecture

For a rust-lightning high-level API introduction, see ARCH.md.

License is either Apache-2.0 or MIT, at the option of the user (ie dual-license Apache-2.0 and MIT).