Trait lightning::sign::NodeSigner

source · 
pub trait NodeSigner {
    // Required methods
    fn get_inbound_payment_key_material(&self) -> KeyMaterial;
    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,
        hrp_bytes: &[u8],
        invoice_data: &[u5],
        recipient: Recipient
    ) -> Result<RecoverableSignature, ()>;
    fn sign_bolt12_invoice_request(
        &self,
        invoice_request: &UnsignedInvoiceRequest
    ) -> Result<Signature, ()>;
    fn sign_bolt12_invoice(
        &self,
        invoice: &UnsignedBolt12Invoice
    ) -> Result<Signature, ()>;
    fn sign_gossip_message(
        &self,
        msg: UnsignedGossipMessage<'_>
    ) -> Result<Signature, ()>;
}
Expand description

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

Required Methods§

source

fn get_inbound_payment_key_material(&self) -> KeyMaterial

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

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 method must return the same value each time it is called.

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, 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_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_request( &self, invoice_request: &UnsignedInvoiceRequest ) -> Result<Signature, ()>

Signs the TaggedHash of a BOLT 12 invoice request.

May be called by a function passed to UnsignedInvoiceRequest::sign where invoice_request is the callee.

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

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.

Implementors§