_ Git - rust-lightning/blob - README.md

   1 Rust-Lightning
   2 ==============
   3
   4 [![Crate](https://img.shields.io/crates/v/lightning.svg?logo=rust)](https://crates.io/crates/lightning)
   5 [![Documentation](https://img.shields.io/static/v1?logo=read-the-docs&label=docs.rs&message=lightning&color=informational)](https://docs.rs/lightning/)
   6 [![Safety Dance](https://img.shields.io/badge/unsafe-forbidden-success.svg)](https://github.com/rust-secure-code/safety-dance/)
   7
   8 Rust-lightning is a Bitcoin Lightning library written in Rust. The main crate,
   9 `lightning`, does not handle networking, persistence, or any other I/O. Thus,
  10 it is runtime-agnostic, but users must implement basic networking logic, chain
  11 interactions, and disk storage.
  12
  13 The `lightning-net-tokio` crate implements Lightning networking using the
  14 [Tokio](https://github.com/tokio-rs/tokio) async runtime.
  15
  16 Status
  17 ------
  18
  19 The project implements all of the BOLT specifications in the 1.0 spec except
  20 for [channel queries](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#query-messages). The
  21 implementation has pretty good test coverage that is expected to continue to
  22 improve. There are a number of internal refactorings being done now that will
  23 make the code base more welcoming to new contributors. It is also anticipated
  24 that as developers begin using the API, the lessons from that will result in
  25 changes to the API, so any developer using this API at this stage should be prepared
  26 to embrace that. The current state is sufficient for a developer or project to
  27 experiment with it. Recent increased contribution rate to the project is expected
  28 to lead to a high quality, stable, production-worthy implementation in 2020.
  29
  30 Communications for Rust-Lightning and Lightning Development Kit happens through
  31 [LDK slack](http://lightningdevkit.org/).
  32
  33 Design Goal
  34 -----------
  35
  36 The goal is to provide a full-featured but also incredibly flexible lightning
  37 implementation, allowing the user to decide how they wish to use it. With that
  38 in mind, everything should be exposed via simple, composable APIs. The user
  39 should be able to decide whether they wish to use their own threading/execution
  40 models, allowing usage inside of existing library architectures, or allow us to
  41 handle that for them. Same goes with network connections - if the user wishes
  42 to use their own networking stack, they should be able to do so! This all means
  43 that we should provide simple external interfaces which allow the user to drive
  44 all execution, while implementing sample execution drivers that create a
  45 full-featured lightning daemon by default.
  46
  47 For security reasons, do not add new dependencies. Really do not add new
  48 non-optional/non-test/non-library dependencies. Really really do not add
  49 dependencies with dependencies. Do convince Andrew to cut down dependency usage
  50 in rust-bitcoin.
  51
  52
  53 Tagline
  54 -------
  55
  56 *"Rust-Lightning, not Rusty's Lightning!"*
  57
  58 Contributing
  59 ------------
  60
  61 Contributors are warmly welcome, see [CONTRIBUTING.md](CONTRIBUTING.md).
  62
  63 Project Architecture
  64 ---------------------
  65
  66 For a Rust-Lightning high-level API introduction, see [ARCH.md](ARCH.md).
  67
  68 License is either Apache-2.0 or MIT, at the option of the user (ie dual-license
  69 Apache-2.0 and MIT).