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.