A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Go to file
Matt Corallo 4395b92cc8 Relicense as dual Apache-2.0 + MIT
This changes the LICENSE file and adds license headers to most files
to relicense under dual Apache-2.0 and MIT. This is helpful in that
we retain the patent grant issued under Apache-2.0-licensed work,
avoiding some sticky patent issues, while still allowing users who
are more comfortable with the simpler MIT license to use that.

See https://github.com/rust-bitcoin/rust-lightning/issues/659 for
relicensing statements from code authors.
2020-08-10 21:12:44 -04:00
.github/workflows Set codecov upload token 2020-08-03 17:09:27 -04:00
fuzz Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
lightning Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
lightning-net-tokio Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00
.editorconfig Mandate new line at end of file in editorconfig. 2020-04-11 11:33:07 -07:00
.gitignore Provide remote channel public keys to signer 2020-01-19 20:40:49 -05:00
.travis.yml Use more generic name as it will be use in GitHub Action too 2020-04-23 09:36:48 +10:00
ARCH.md Improve routing-related documentation 2020-05-12 09:27:12 -04:00
Cargo.toml Move test profile to crate root, so it has effect again 2019-11-28 01:21:41 -05:00
CONTRIBUTING.md Merge pull request #507 from moneyball/patch-2 2020-02-29 02:59:34 +00: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 Relicense as dual Apache-2.0 + MIT 2020-08-10 21:12:44 -04:00

Safety Dance

Rust-Lightning, not Rusty's Lightning!

Documentation can be found at docs.rs

The project implements all of the BOLT specifications in the 1.0 spec except for channel queries. The implementation has pretty good test coverage that is expected to continue to improve. There are a number of internal refactorings being done now that will make the code base more welcoming to new contributors. It is also anticipated that as developers begin using the API, the lessons from that will result in changes to the API, so any developer using this API at this stage should be prepared to embrace that. The current state is sufficient for a developer or project to experiment with it. Recent increased contribution rate to the project is expected to lead to a high quality, stable, production-worthy implementation in 2020.

Communications for Rust-Lightning and Lightning Development Kit happens through LDK slack.

Design Goal

The goal is to provide a full-featured but also incredibly flexible lightning implementation, allowing the user to decide how they wish to use it. With that in mind, everything should be exposed via simple, composable APIs. The user should be able to decide whether they wish to use their own threading/execution models, allowing usage inside of existing library architectures, or allow us to handle that for them. Same goes with network connections - if the user wishes to use their own networking stack, they should be able to do so! This all means that we should provide simple external interfaces which allow the user to drive all execution, while implementing sample execution drivers that create a full-featured lightning daemon by default.

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.

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).