+/// Set of lightning keys needed to operate a channel as described in BOLT 3.
+///
+/// Signing services could be implemented on a hardware wallet. In this case,
+/// the current ChannelKeys 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.
+///
+/// If you're implementing a custom signer, you almost certainly want to implement
+/// Readable/Writable to serialize out a unique reference to this set of keys so
+/// that you can serialize the full ChannelManager object.
+///
+/// (TODO: We shouldn't require that, and should have an API to get them at deser time, due mostly
+/// to the possibility of reentrancy issues by calling the user's code during our deserialization
+/// routine).
+pub trait ChannelKeys : Send {
+ /// Gets the private key for the anchor tx
+ fn funding_key<'a>(&'a self) -> &'a SecretKey;
+ /// Gets the local secret key for blinded revocation pubkey
+ fn revocation_base_key<'a>(&'a self) -> &'a SecretKey;
+ /// Gets the local secret key used in to_remote output of remote commitment tx
+ /// (and also as part of obscured commitment number)
+ fn payment_base_key<'a>(&'a self) -> &'a SecretKey;
+ /// Gets the local secret key used in HTLC-Success/HTLC-Timeout txn and to_local output
+ fn delayed_payment_base_key<'a>(&'a self) -> &'a SecretKey;
+ /// Gets the local htlc secret key used in commitment tx htlc outputs
+ fn htlc_base_key<'a>(&'a self) -> &'a SecretKey;
+ /// Gets the commitment seed
+ fn commitment_seed<'a>(&'a self) -> &'a [u8; 32];
+
+ /// Create a signature for a remote commitment transaction and associated HTLC transactions.
+ ///
+ /// Note that if signing fails or is rejected, the channel will be force-closed.
+ ///
+ /// TODO: Document the things someone using this interface should enforce before signing.
+ /// TODO: Add more input vars to enable better checking (preferably removing commitment_tx and
+ /// making the callee generate it via some util function we expose)!
+ fn sign_remote_commitment<T: secp256k1::Signing>(&self, channel_value_satoshis: u64, channel_funding_redeemscript: &Script, absolute_fee: u64, commitment_tx: &Transaction, keys: &TxCreationKeys, htlcs: &[&HTLCOutputInCommitment], to_self_delay: u16, secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()>;
+
+ /// 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_closing_transaction<T: secp256k1::Signing>(&self, channel_value_satoshis: u64, channel_funding_redeemscript: &Script, closing_tx: &Transaction, secp_ctx: &Secp256k1<T>) -> Result<Signature, ()>;
+
+ /// 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 sign_channel_announcement<T: secp256k1::Signing>(&self, msg: &msgs::UnsignedChannelAnnouncement, secp_ctx: &Secp256k1<T>) -> Result<Signature, ()>;
+}
+