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.