Struct lightning::chain::keysinterface::PhantomKeysManager

pub struct PhantomKeysManager { /* private fields */ }

Similar to KeysManager, but allows the node using this struct to receive phantom node payments.

A phantom node payment is a payment made to a phantom invoice, which is an invoice that can be paid to one of multiple nodes. This works because we encode the invoice route hints such that LDK will recognize an incoming payment as destined for a phantom node, and collect the payment itself without ever needing to forward to this fake node.

Phantom node payments are useful for load balancing between multiple LDK nodes. They also provide some fault tolerance, because payers will automatically retry paying other provided nodes in the case that one node goes down.

Note that multi-path payments are not supported in phantom invoices for security reasons. Switching between this struct and KeysManager will invalidate any previously issued invoices and attempts to pay previous invoices will fail.

Implementations

impl PhantomKeysManager

pub fn new(
    seed: &[u8; 32],
    starting_time_secs: u64,
    starting_time_nanos: u32,
    cross_node_seed: &[u8; 32]
) -> Self

Constructs a PhantomKeysManager given a 32-byte seed and an additional cross_node_seed that is shared across all nodes that intend to participate in phantom node payments together.

See KeysManager::new for more information on seed, starting_time_secs, and starting_time_nanos.

cross_node_seed must be the same across all phantom payment-receiving nodes and also the same across restarts, or else inbound payments may fail.

pub fn spend_spendable_outputs<C: Signing>(
    &self,
    descriptors: &[&SpendableOutputDescriptor],
    outputs: Vec<TxOut>,
    change_destination_script: Script,
    feerate_sat_per_1000_weight: u32,
    secp_ctx: &Secp256k1<C>
) -> Result<Transaction, ()>

See KeysManager::spend_spendable_outputs for documentation on this method.

pub fn derive_channel_keys(
    &self,
    channel_value_satoshis: u64,
    params: &[u8; 32]
) -> InMemorySigner

See KeysManager::derive_channel_keys for documentation on this method.

Trait Implementations

impl KeysInterface for PhantomKeysManager

type Signer = InMemorySigner

A type which implements Sign which will be returned by get_channel_signer.

fn get_node_secret(&self, recipient: Recipient) -> Result<SecretKey, ()>

Get node secret key based on the provided Recipient.

fn get_inbound_payment_key_material(&self) -> KeyMaterial

Get secret key material as bytes for use in encrypting and decrypting inbound payment data.

fn get_destination_script(&self) -> Script

Get a script pubkey which we send funds to when claiming on-chain contestable outputs.

fn get_shutdown_scriptpubkey(&self) -> ShutdownScript

Get a script pubkey which we will send funds to when closing a channel.

fn get_channel_signer(
    &self,
    inbound: bool,
    channel_value_satoshis: u64
) -> Self::Signer

Get a new set of Sign for per-channel secrets. These MUST be unique even if you restarted with some stale data!

fn get_secure_random_bytes(&self) -> [u8; 32]

Gets a unique, cryptographically-secure, random 32 byte value. This is used for encrypting onion packets and for temporary channel IDs. There is no requirement that these be persisted anywhere, though they must be unique across restarts.

fn read_chan_signer(&self, reader: &[u8]) -> Result<Self::Signer, DecodeError>

Reads a Signer for this KeysInterface from the given input stream. This is only called during deserialization of other objects which contain Sign-implementing objects (ie ChannelMonitors and ChannelManagers). The bytes are exactly those which <Self::Signer as Writeable>::write() writes, and contain no versioning scheme. You may wish to include your own version prefix and ensure you’ve read all of the provided bytes to ensure no corruption occurred.

fn sign_invoice(
    &self,
    hrp_bytes: &[u8],
    invoice_data: &[u5],
    recipient: Recipient
) -> Result<RecoverableSignature, ()>

Sign an invoice. By parameterizing by the raw invoice bytes instead of the hash, we allow implementors of this trait to parse the invoice and make sure they’re signing what they expect, rather than blindly signing the hash. The hrp is ascii bytes, while the invoice data is base32.