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

check_added_monitors

Check whether N channel monitor(s) have been added.

check_closed_broadcast

Check that a channel’s closing channel update has been broadcasted, and optionally check whether an error message event has occurred.

check_closed_event

Check that a channel’s closing channel events has been issued

check_spends

commitment_signed_dance

Performs the “commitment signed dance” - the series of message exchanges which occur after a commitment update.

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.

expect_htlc_handling_failed_destinations

expect_payment_claimable

expect_payment_claimed

expect_payment_sent

expect_pending_htlcs_forwardable

Handles a PendingHTLCsForwardable event

expect_pending_htlcs_forwardable_and_htlc_handling_failed

Handles a PendingHTLCsForwardable and HTLCHandlingFailed event

expect_pending_htlcs_forwardable_and_htlc_handling_failed_ignore

Clears (and ignores) PendingHTLCsForwardable and HTLCHandlingFailed events

expect_pending_htlcs_forwardable_conditions

Don’t use this, use the identically-named function instead.

expect_pending_htlcs_forwardable_ignore

Clears (and ignores) a PendingHTLCsForwardable event

get_event

Get a specific event from the pending events queue.

get_event_msg

Get an specific event message from the pending events queue.

get_htlc_update_msgs

Gets an UpdateHTLCs MessageSendEvent

get_local_commitment_txn

Returns any local commitment transactions for the channel.

get_monitor

Returns a channel monitor given a channel id, making some naive assumptions

get_payment_preimage_hash

Get a payment preimage and hash.

get_revoke_commit_msgs

Gets an RAA and CS which were sent in response to a commitment update

get_route

Gets a route from the given sender to the node described in payment_params.

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.

unwrap_send_err

Check the error from attempting a payment.

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.