+/// 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).
+// TODO: We should remove Clone by instead requesting a new ChannelKeys copy when we create
+// ChannelMonitors instead of expecting to clone the one out of the Channel into the monitors.
+pub trait ChannelKeys : Send+Clone + Writeable {
+ /// Gets the per-commitment point for a specific commitment number
+ ///
+ /// Note that the commitment number starts at (1 << 48) - 1 and counts backwards.
+ fn get_per_commitment_point<T: secp256k1::Signing + secp256k1::Verification>(&self, idx: u64, secp_ctx: &Secp256k1<T>) -> PublicKey;
+ /// 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.
+ /// TODO: return a Result so we can signal a validation error
+ fn release_commitment_secret(&self, idx: u64) -> [u8; 32];
+ /// Gets the holder's channel public keys and basepoints
+ fn pubkeys(&self) -> &ChannelPublicKeys;
+ /// Gets arbitrary identifiers describing the set of keys which are provided back to you in
+ /// some SpendableOutputDescriptor types. These should be sufficient to identify this
+ /// ChannelKeys object uniquely and lookup or re-derive its keys.
+ fn key_derivation_params(&self) -> (u64, u64);
+
+ /// 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.
+ //
+ // TODO: Document the things someone using this interface should enforce before signing.
+ fn sign_counterparty_commitment<T: secp256k1::Signing + secp256k1::Verification>(&self, commitment_tx: &CommitmentTransaction, secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()>;
+
+ /// 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.
+ //
+ // TODO: Document the things someone using this interface should enforce before signing.
+ // TODO: Key derivation failure should panic rather than Err
+ fn sign_holder_commitment_and_htlcs<T: secp256k1::Signing + secp256k1::Verification>(&self, commitment_tx: &HolderCommitmentTransaction, secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()>;
+
+ /// Same as sign_holder_commitment, but exists only for tests to get access to holder commitment
+ /// transactions which will be broadcasted later, after the channel has moved on to a newer
+ /// state. Thus, needs its own method as sign_holder_commitment may enforce that we only ever
+ /// get called once.
+ #[cfg(any(test,feature = "unsafe_revoked_tx_signing"))]
+ fn unsafe_sign_holder_commitment_and_htlcs<T: secp256k1::Signing + secp256k1::Verification>(&self, commitment_tx: &HolderCommitmentTransaction, secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()>;
+
+ /// 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_justice_transaction<T: secp256k1::Signing + secp256k1::Verification>(&self, justice_tx: &Transaction, input: usize, amount: u64, per_commitment_key: &SecretKey, htlc: &Option<HTLCOutputInCommitment>, secp_ctx: &Secp256k1<T>) -> Result<Signature, ()>;
+
+ /// 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_counterparty_htlc_transaction<T: secp256k1::Signing + secp256k1::Verification>(&self, htlc_tx: &Transaction, input: usize, amount: u64, per_commitment_point: &PublicKey, htlc: &HTLCOutputInCommitment, secp_ctx: &Secp256k1<T>) -> Result<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, 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: &UnsignedChannelAnnouncement, secp_ctx: &Secp256k1<T>) -> Result<Signature, ()>;
+
+ /// 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.
+ fn ready_channel(&mut self, channel_parameters: &ChannelTransactionParameters);
+}
+