+typedef struct LDKCResultTempl_CVecTempl_Signature_____u8 LDKCResult_CVec_SignatureZNoneZ;
+
+
+
+/**
+ * Information about an HTLC as it appears in a commitment transaction
+ */
+typedef struct MUST_USE_STRUCT LDKHTLCOutputInCommitment {
+ /**
+ * Nearly everywhere, inner must be non-null, however in places where
+ * the Rust equivalent takes an Option, it may be set to null to indicate None.
+ */
+ LDKnativeHTLCOutputInCommitment *inner;
+ bool is_owned;
+} LDKHTLCOutputInCommitment;
+
+
+
+/**
+ * The unsigned part of a channel_announcement
+ */
+typedef struct MUST_USE_STRUCT LDKUnsignedChannelAnnouncement {
+ /**
+ * Nearly everywhere, inner must be non-null, however in places where
+ * the Rust equivalent takes an Option, it may be set to null to indicate None.
+ */
+ LDKnativeUnsignedChannelAnnouncement *inner;
+ bool is_owned;
+} LDKUnsignedChannelAnnouncement;
+
+
+
+/**
+ * Per-channel data used to build transactions in conjunction with the per-commitment data (CommitmentTransaction).
+ * The fields are organized by holder/counterparty.
+ *
+ * Normally, this is converted to the broadcaster/countersignatory-organized DirectedChannelTransactionParameters
+ * before use, via the as_holder_broadcastable and as_counterparty_broadcastable functions.
+ */
+typedef struct MUST_USE_STRUCT LDKChannelTransactionParameters {
+ /**
+ * Nearly everywhere, inner must be non-null, however in places where
+ * the Rust equivalent takes an Option, it may be set to null to indicate None.
+ */
+ LDKnativeChannelTransactionParameters *inner;
+ bool is_owned;
+} LDKChannelTransactionParameters;
+
+/**
+ * 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.
+ *
+ */
+typedef struct LDKChannelKeys {
+ void *this_arg;
+ /**
+ * Gets the per-commitment point for a specific commitment number
+ *
+ * Note that the commitment number starts at (1 << 48) - 1 and counts backwards.
+ */
+ struct LDKPublicKey (*get_per_commitment_point)(const void *this_arg, uint64_t idx);
+ /**
+ * 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
+ */
+ struct LDKThirtyTwoBytes (*release_commitment_secret)(const void *this_arg, uint64_t idx);
+ /**
+ * Gets the holder's channel public keys and basepoints
+ */
+ struct LDKChannelPublicKeys pubkeys;
+ /**
+ * Fill in the pubkeys field as a reference to it will be given to Rust after this returns
+ * Note that this takes a pointer to this object, not the this_ptr like other methods do
+ * This function pointer may be NULL if pubkeys is filled in when this object is created and never needs updating.
+ */
+ void (*set_pubkeys)(const struct LDKChannelKeys*NONNULL_PTR );
+ /**
+ * 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.
+ */
+ LDKC2Tuple_u64u64Z (*key_derivation_params)(const void *this_arg);
+ /**
+ * 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.
+ */
+ LDKCResult_C2Tuple_SignatureCVec_SignatureZZNoneZ (*sign_counterparty_commitment)(const void *this_arg, const struct LDKCommitmentTransaction *NONNULL_PTR commitment_tx);
+ /**
+ * Create a signature for a holder's commitment transaction. This will only ever be called with
+ * the same commitment_tx (or a copy thereof), though there are currently no guarantees
+ * that it will not be called multiple times.
+ * An external signer implementation should check that the commitment has not been revoked.
+ */
+ LDKCResult_SignatureNoneZ (*sign_holder_commitment)(const void *this_arg, const struct LDKHolderCommitmentTransaction *NONNULL_PTR commitment_tx);
+ /**
+ * Create a signature for each HTLC transaction spending a holder's commitment transaction.
+ *
+ * Unlike sign_holder_commitment, this may be called multiple times with *different*
+ * commitment_tx values. While this will never be called with a revoked
+ * commitment_tx, it is possible that it is called with the second-latest
+ * commitment_tx (only if we haven't yet revoked it) if some watchtower/secondary
+ * ChannelMonitor decided to broadcast before it had been updated to the latest.
+ *
+ * Either an Err should be returned, or a Vec with one entry for each HTLC which exists in
+ * commitment_tx.
+ */
+ LDKCResult_CVec_SignatureZNoneZ (*sign_holder_commitment_htlc_transactions)(const void *this_arg, const struct LDKHolderCommitmentTransaction *NONNULL_PTR commitment_tx);
+ /**
+ * 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).
+ */
+ LDKCResult_SignatureNoneZ (*sign_justice_transaction)(const void *this_arg, struct LDKTransaction justice_tx, uintptr_t input, uint64_t amount, const uint8_t (*per_commitment_key)[32], const struct LDKHTLCOutputInCommitment *NONNULL_PTR htlc);
+ /**
+ * 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.
+ */
+ LDKCResult_SignatureNoneZ (*sign_counterparty_htlc_transaction)(const void *this_arg, struct LDKTransaction htlc_tx, uintptr_t input, uint64_t amount, struct LDKPublicKey per_commitment_point, const struct LDKHTLCOutputInCommitment *NONNULL_PTR htlc);
+ /**
+ * 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.
+ */
+ LDKCResult_SignatureNoneZ (*sign_closing_transaction)(const void *this_arg, struct LDKTransaction closing_tx);
+ /**
+ * 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.
+ */
+ LDKCResult_SignatureNoneZ (*sign_channel_announcement)(const void *this_arg, const struct LDKUnsignedChannelAnnouncement *NONNULL_PTR msg);
+ /**
+ * 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.
+ */
+ void (*ready_channel)(void *this_arg, const struct LDKChannelTransactionParameters *NONNULL_PTR channel_parameters);
+ void *(*clone)(const void *this_arg);
+ LDKCVec_u8Z (*write)(const void *this_arg);
+ void (*free)(void *this_arg);
+} LDKChannelKeys;
+
+
+
+/**
+ * A ChannelMonitor handles chain events (blocks connected and disconnected) and generates
+ * on-chain transactions to ensure no loss of funds occurs.
+ *
+ * You MUST ensure that no ChannelMonitors for a given channel anywhere contain out-of-date
+ * information and are actively monitoring the chain.
+ *
+ * Pending Events or updated HTLCs which have not yet been read out by
+ * get_and_clear_pending_monitor_events or get_and_clear_pending_events are serialized to disk and
+ * reloaded at deserialize-time. Thus, you must ensure that, when handling events, all events
+ * gotten are fully handled before re-serializing the new state.
+ *
+ * Note that the deserializer is only implemented for (Sha256dHash, ChannelMonitor), which
+ * tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along
+ * the \"reorg path\" (ie disconnecting blocks until you find a common ancestor from both the
+ * returned block hash and the the current chain and then reconnecting blocks to get to the
+ * best chain) upon deserializing the object!
+ */
+typedef struct MUST_USE_STRUCT LDKChannelMonitor {
+ /**
+ * Nearly everywhere, inner must be non-null, however in places where
+ * the Rust equivalent takes an Option, it may be set to null to indicate None.
+ */
+ LDKnativeChannelMonitor *inner;
+ bool is_owned;
+} LDKChannelMonitor;
+
+typedef struct LDKC2TupleTempl_ThirtyTwoBytes__ChannelMonitor {
+ struct LDKThirtyTwoBytes a;
+ struct LDKChannelMonitor b;
+} LDKC2TupleTempl_ThirtyTwoBytes__ChannelMonitor;
+
+typedef struct LDKC2TupleTempl_ThirtyTwoBytes__ChannelMonitor LDKC2Tuple_BlockHashChannelMonitorZ;
+
+typedef struct LDKC2TupleTempl_Signature__CVecTempl_Signature LDKC2Tuple_SignatureCVec_SignatureZZ;
+
+typedef struct LDKCVecTempl_Signature LDKCVec_SignatureZ;