lightning::sign

Trait NodeSigner

Source 
pub trait NodeSigner {
    // Required methods
    fn get_expanded_key(&self) -> ExpandedKey;
    fn get_peer_storage_key(&self) -> PeerStorageKey;
    fn get_receive_auth_key(&self) -> ReceiveAuthKey;
    fn get_node_id(&self, recipient: Recipient) -> Result<PublicKey, ()>;
    fn ecdh(
        &self,
        recipient: Recipient,
        other_key: &PublicKey,
        tweak: Option<&Scalar>,
    ) -> Result<SharedSecret, ()>;
    fn sign_invoice(
        &self,
        invoice: &RawBolt11Invoice,
        recipient: Recipient,
    ) -> Result<RecoverableSignature, ()>;
    fn sign_bolt12_invoice(
        &self,
        invoice: &UnsignedBolt12Invoice,
    ) -> Result<Signature, ()>;
    fn sign_gossip_message(
        &self,
        msg: UnsignedGossipMessage<'_>,
    ) -> Result<Signature, ()>;
    fn sign_message(&self, msg: &[u8]) -> Result<String, ()>;
}
Expand description

A trait that can handle cryptographic operations at the scope level of a node.

Required Methods§

Source

fn get_expanded_key(&self) -> ExpandedKey

Get the ExpandedKey which provides cryptographic material for various Lightning Network operations.

This key set is used for:

  • Encrypting and decrypting inbound payment metadata
  • Authenticating payment hashes (both LDK-provided and user-provided)
  • Supporting BOLT 12 Offers functionality (key derivation and authentication)
  • Authenticating spontaneous payments’ metadata

This method must return the same value each time it is called.

If the implementor of this trait supports phantom node payments, then every node that is intended to be included in the phantom invoice route hints must return the same value from this method. This is because LDK avoids storing inbound payment data. Instead, this key is used to construct a payment secret which is received in the payment onion and used to reconstruct the payment preimage. Therefore, for a payment to be receivable by multiple nodes, they must share the same key.

Source

fn get_peer_storage_key(&self) -> PeerStorageKey

Defines a method to derive a 32-byte encryption key for peer storage.

Implementations of this method must derive a secure encryption key. The key is used to encrypt or decrypt backups of our state stored with our peers.

Thus, if you wish to rely on recovery using this method, you should use a key which can be re-derived from data which would be available after state loss (eg the wallet seed).

Source

fn get_receive_auth_key(&self) -> ReceiveAuthKey

Returns the ReceiveAuthKey used to authenticate incoming BlindedMessagePath contexts.

This key is used as additional associated data (AAD) during MAC verification of the MessageContext at the final hop of a blinded path. It ensures that only paths constructed by this node will be accepted, preventing unauthorized parties from forging valid-looking messages.

Implementers must ensure that this key remains secret and consistent across invocations.

Source

fn get_node_id(&self, recipient: Recipient) -> Result<PublicKey, ()>

Get node id based on the provided Recipient.

This method must return the same value each time it is called with a given Recipient parameter.

Errors if the Recipient variant is not supported by the implementation.

Source

fn ecdh( &self, recipient: Recipient, other_key: &PublicKey, tweak: Option<&Scalar>, ) -> Result<SharedSecret, ()>

Gets the ECDH shared secret of our node secret and other_key, multiplying by tweak if one is provided. Note that this tweak can be applied to other_key instead of our node secret, though this is less efficient.

Note that if this fails while attempting to forward an HTLC, LDK will panic. The error should be resolved to allow LDK to resume forwarding HTLCs.

Errors if the Recipient variant is not supported by the implementation.

Source

fn sign_invoice( &self, invoice: &RawBolt11Invoice, 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_bytes are ASCII bytes, while the invoice_data is base32.

The secret key used to sign the invoice is dependent on the Recipient.

Errors if the Recipient variant is not supported by the implementation.

Source

fn sign_bolt12_invoice( &self, invoice: &UnsignedBolt12Invoice, ) -> Result<Signature, ()>

Signs the TaggedHash of a BOLT 12 invoice.

May be called by a function passed to UnsignedBolt12Invoice::sign where invoice is the callee.

Implementors may check that the invoice is expected rather than blindly signing the tagged hash. An Ok result should sign invoice.tagged_hash().as_digest() with the node’s signing key or an ephemeral key to preserve privacy, whichever is associated with UnsignedBolt12Invoice::signing_pubkey.

Source

fn sign_gossip_message( &self, msg: UnsignedGossipMessage<'_>, ) -> Result<Signature, ()>

Sign a gossip message.

Note that if this fails, LDK may panic and the message will not be broadcast to the network or a possible channel counterparty. If LDK panics, the error should be resolved to allow the message to be broadcast, as otherwise it may prevent one from receiving funds over the corresponding channel.

Source

fn sign_message(&self, msg: &[u8]) -> Result<String, ()>

Sign an arbitrary message with the node’s secret key.

Creates a digital signature of a message given the node’s secret. The message is prefixed with “Lightning Signed Message:” before signing. See this description of the format for more details.

A receiver knowing the node’s id and the message can be sure that the signature was generated by the caller. An Err can be returned to signal that the signer is unavailable / cannot produce a valid signature.

Implementors§