Trait lightning::chain::keysinterface::Sign[−][src]

pub trait Sign: Send + Clone + Writeable {
    fn get_per_commitment_point<T: Signing + Verification>(
        &self, 
        idx: u64, 
        secp_ctx: &Secp256k1<T>
    ) -> PublicKey;

    fn release_commitment_secret(&self, idx: u64) -> [u8; 32];

    fn pubkeys(&self) -> &ChannelPublicKeys;

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

    fn sign_counterparty_commitment<T: Signing + Verification>(
        &self, 
        commitment_tx: &CommitmentTransaction, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<(Signature, Vec<Signature>), ()>;

    fn sign_holder_commitment_and_htlcs<T: Signing + Verification>(
        &self, 
        commitment_tx: &HolderCommitmentTransaction, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<(Signature, Vec<Signature>), ()>;

    fn sign_justice_transaction<T: Signing + Verification>(
        &self, 
        justice_tx: &Transaction, 
        input: usize, 
        amount: u64, 
        per_commitment_key: &SecretKey, 
        htlc: &Option<HTLCOutputInCommitment>, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<Signature, ()>;

    fn sign_counterparty_htlc_transaction<T: Signing + Verification>(
        &self, 
        htlc_tx: &Transaction, 
        input: usize, 
        amount: u64, 
        per_commitment_point: &PublicKey, 
        htlc: &HTLCOutputInCommitment, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<Signature, ()>;

    fn sign_closing_transaction<T: Signing>(
        &self, 
        closing_tx: &Transaction, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<Signature, ()>;

    fn sign_channel_announcement<T: Signing>(
        &self, 
        msg: &UnsignedChannelAnnouncement, 
        secp_ctx: &Secp256k1<T>
    ) -> Result<Signature, ()>;

    fn ready_channel(
        &mut self, 
        channel_parameters: &ChannelTransactionParameters
    );
}

A trait to sign lightning channel transactions as described in BOLT 3.

Signing services could be implemented on a hardware wallet. In this case, the current Sign would be a front-end on top of a communication channel connected to your secure device and lightning key material wouldn’t reside on a hot server. Nevertheless, a this deployment would still need to trust the ChannelManager to avoid loss of funds as this latest component could ask to sign commitment transaction with HTLCs paying to attacker pubkeys.

A more secure iteration would be to use hashlock (or payment points) to pair invoice/incoming HTLCs with outgoing HTLCs to implement a no-trust-ChannelManager at the price of more state and computation on the hardware wallet side. In the future, we are looking forward to design such interface.

In any case, ChannelMonitor or fallback watchtowers are always going to be trusted to act, as liveness and breach reply correctness are always going to be hard requirements of LN security model, orthogonal of key management issues.

Required methods

fn get_per_commitment_point<T: Signing + Verification>(
    &self,
    idx: u64,
    secp_ctx: &Secp256k1<T>
) -> PublicKey[src]

Gets the per-commitment point for a specific commitment number

Note that the commitment number starts at (1 << 48) - 1 and counts backwards.

fn release_commitment_secret(&self, idx: u64) -> [u8; 32][src]

Gets the commitment secret for a specific commitment number as part of the revocation process

An external signer implementation should error here if the commitment was already signed and should refuse to sign it in the future.

May be called more than once for the same index.

Note that the commitment number starts at (1 << 48) - 1 and counts backwards.

fn pubkeys(&self) -> &ChannelPublicKeys[src]

Gets the holder’s channel public keys and basepoints

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

Gets an arbitrary identifier describing the set of keys which are provided back to you in some SpendableOutputDescriptor types. This should be sufficient to identify this Sign object uniquely and lookup or re-derive its keys.

fn sign_counterparty_commitment<T: Signing + Verification>(
    &self,
    commitment_tx: &CommitmentTransaction,
    secp_ctx: &Secp256k1<T>
) -> Result<(Signature, Vec<Signature>), ()>[src]

Create a signature for a counterparty’s commitment transaction and associated HTLC transactions.

Note that if signing fails or is rejected, the channel will be force-closed.

fn sign_holder_commitment_and_htlcs<T: Signing + Verification>(
    &self,
    commitment_tx: &HolderCommitmentTransaction,
    secp_ctx: &Secp256k1<T>
) -> Result<(Signature, Vec<Signature>), ()>[src]

Create a signatures for a holder’s commitment transaction and its claiming HTLC transactions. This will only ever be called with a non-revoked commitment_tx. This will be called with the latest commitment_tx when we initiate a force-close. This will be called with the previous latest, just to get claiming HTLC signatures, if we are reacting to a ChannelMonitor replica that decided to broadcast before it had been updated to the latest. This may be called multiple times for the same transaction.

An external signer implementation should check that the commitment has not been revoked.

May return Err if key derivation fails. Callers, such as ChannelMonitor, will panic in such a case.

fn sign_justice_transaction<T: Signing + Verification>(
    &self,
    justice_tx: &Transaction,
    input: usize,
    amount: u64,
    per_commitment_key: &SecretKey,
    htlc: &Option<HTLCOutputInCommitment>,
    secp_ctx: &Secp256k1<T>
) -> Result<Signature, ()>[src]

Create a signature for the given input in a transaction spending an HTLC or commitment transaction output when our counterparty broadcasts an old state.

A justice transaction may claim multiples outputs at the same time if timelocks are similar, but only a signature for the input at index input should be signed for here. It may be called multiples time for same output(s) if a fee-bump is needed with regards to an upcoming timelock expiration.

Amount is value of the output spent by this input, committed to in the BIP 143 signature.

per_commitment_key is revocation secret which was provided by our counterparty when they revoked the state which they eventually broadcast. It’s not a holder secret key and does not allow the spending of any funds by itself (you need our holder revocation_secret to do so).

htlc holds HTLC elements (hash, timelock) if the output being spent is a HTLC output, thus changing the format of the witness script (which is committed to in the BIP 143 signatures).

fn sign_counterparty_htlc_transaction<T: Signing + Verification>(
    &self,
    htlc_tx: &Transaction,
    input: usize,
    amount: u64,
    per_commitment_point: &PublicKey,
    htlc: &HTLCOutputInCommitment,
    secp_ctx: &Secp256k1<T>
) -> Result<Signature, ()>[src]

Create a signature for a claiming transaction for a HTLC output on a counterparty’s commitment transaction, either offered or received.

Such a transaction may claim multiples offered outputs at same time if we know the preimage for each when we create it, but only the input at index input should be signed for here. It may be called multiple times for same output(s) if a fee-bump is needed with regards to an upcoming timelock expiration.

Witness_script is either a offered or received script as defined in BOLT3 for HTLC outputs.

Amount is value of the output spent by this input, committed to in the BIP 143 signature.

Per_commitment_point is the dynamic point corresponding to the channel state detected onchain. It has been generated by our counterparty and is used to derive channel state keys, which are then included in the witness script and committed to in the BIP 143 signature.

fn sign_closing_transaction<T: Signing>(
    &self,
    closing_tx: &Transaction,
    secp_ctx: &Secp256k1<T>
) -> Result<Signature, ()>[src]

Create a signature for a (proposed) closing transaction.

Note that, due to rounding, there may be one “missing” satoshi, and either party may have chosen to forgo their output as dust.

fn sign_channel_announcement<T: Signing>(
    &self,
    msg: &UnsignedChannelAnnouncement,
    secp_ctx: &Secp256k1<T>
) -> Result<Signature, ()>[src]

Signs a channel announcement message with our funding key, proving it comes from one of the channel participants.

Note that if this fails or is rejected, the channel will not be publicly announced and our counterparty may (though likely will not) close the channel on us for violating the protocol.

fn ready_channel(&mut self, channel_parameters: &ChannelTransactionParameters)[src]

Set the counterparty static channel data, including basepoints, counterparty_selected/holder_selected_contest_delay and funding outpoint. This is done as soon as the funding outpoint is known. Since these are static channel data, they MUST NOT be allowed to change to different values once set.

channel_parameters.is_populated() MUST be true.

We bind holder_selected_contest_delay late here for API convenience.

Will be called before any signatures are applied.

Loading content...

Implementors

impl Sign for InMemorySigner[src]

Loading content...