Crate lightning

Rust-Lightning, not Rusty’s Lightning!

A full-featured but also flexible lightning implementation, in library form. This allows the user (you) to decide how they wish to use it instead of being a fully self-contained daemon. This means there is no built-in threading/execution environment and it’s up to the user to figure out how best to make networking happen/timers fire/things get written to disk/keys get generated/etc. This makes it a good candidate for tight integration into an existing wallet instead of having a rather-separate lightning appendage to a wallet.

default features are:

• std - enables functionalities which require std, including std::io trait implementations and things which utilize time
• grind_signatures - enables generation of low-r bitcoin signatures, which saves 1 byte per signature in 50% of the cases (see bitcoin PR #13666)

Available features are:

• std
• grind_signatures
• no-std - exposes write trait implementations from the core2 crate (at least one of no-std or std are required)
• Skip logging of messages at levels below the given log level:
  • max_level_off
  • max_level_error
  • max_level_warn
  • max_level_info
  • max_level_debug
  • max_level_trace

Modules

blinded_path

Creating blinded paths and related utilities live here.

chain

Structs and traits which allow other parts of rust-lightning to interact with the blockchain.

events

Events are returned from various bits in the library which indicate some action must be taken by the client.

io

Traits, helpers, and type definitions for core I/O functionality.

ln

Implementations of various parts of the Lightning protocol are in this module.

offers

Implementation of Lightning Offers (BOLT 12).

onion_message

Onion Messages: sending, receiving, forwarding, and ancillary utilities live here

routing

Structs and impls for receiving messages about the network and storing the topology live here.

sign

Provides keys to LDK and defines some useful objects describing spendable on-chain outputs.

util

Some utility modules live here. See individual sub-modules for more info.

Macros

decode_tlv_stream

Implements the TLVs deserialization part in a Readable implementation of a struct.

encode_tlv_stream

Implements the TLVs serialization part in a Writeable implementation of a struct.

impl_writeable_msg

Implements Readable/Writeable for a message struct that may include non-TLV and TLV-encoded parts.

impl_writeable_tlv_based

Implements Readable/Writeable for a struct storing it as a set of TLVs If $fieldty is required, then $field is a required field that is not an Option nor a Vec. If $fieldty is (default_value, $default), then $field will be set to $default if not present. If $fieldty is option, then $field is optional field. If $fieldty is optional_vec, then $field is a Vec, which needs to have its individual elements serialized. Note that for optional_vec no bytes are written if the vec is empty

impl_writeable_tlv_based_enum

Implement Readable and Writeable for an enum, with struct variants stored as TLVs and tuple variants stored directly. The format is, for example

impl_writeable_tlv_based_enum_upgradable

Implement MaybeReadable and Writeable for an enum, with struct variants stored as TLVs and tuple variants stored directly.

log_bytes

Logs a byte slice in hex format.

log_debug

Log at the DEBUG level.

log_error

Log at the ERROR level.

log_gossip

Log at the GOSSIP level.

log_info

Log at the INFO level.

log_pubkey

Logs a pubkey in hex format.

log_trace

Log at the TRACE level.

log_warn

Log at the WARN level.

read_tlv_fields

Reads a suffix added by write_tlv_fields.

write_tlv_fields

Writes out a suffix to an object as a length-prefixed TLV stream which contains potentially backwards-compatible, optional fields which old nodes can happily ignore.