+ * The preimage to the payment_hash, if the payment hash (and secret) were fetched via
+ * [`ChannelManager::create_inbound_payment`]. If provided, this can be handed directly to
+ * [`ChannelManager::claim_funds`].
+ *
+ * [`ChannelManager::create_inbound_payment`]: crate::ln::channelmanager::ChannelManager::create_inbound_payment
+ * [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
+ *
+ * Note that this (or a relevant inner pointer) may be NULL or all-0s to represent None
+ */
+ struct LDKThirtyTwoBytes payment_preimage;
+ /**
+ * The \"payment secret\". This authenticates the sender to the recipient, preventing a
+ * number of deanonymization attacks during the routing process.
+ * It is provided here for your reference, however its accuracy is enforced directly by
+ * [`ChannelManager`] using the values you previously provided to
+ * [`ChannelManager::create_inbound_payment`] or
+ * [`ChannelManager::create_inbound_payment_for_hash`].
+ *
+ * [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
+ * [`ChannelManager::create_inbound_payment`]: crate::ln::channelmanager::ChannelManager::create_inbound_payment
+ * [`ChannelManager::create_inbound_payment_for_hash`]: crate::ln::channelmanager::ChannelManager::create_inbound_payment_for_hash
+ */
+ struct LDKThirtyTwoBytes payment_secret;
+ /**
+ * This is the `user_payment_id` which was provided to
+ * [`ChannelManager::create_inbound_payment_for_hash`] or
+ * [`ChannelManager::create_inbound_payment`]. It has no meaning inside of LDK and is
+ * simply copied here. It may be used to correlate PaymentReceived events with invoice
+ * metadata stored elsewhere.
+ *
+ * [`ChannelManager::create_inbound_payment`]: crate::ln::channelmanager::ChannelManager::create_inbound_payment
+ * [`ChannelManager::create_inbound_payment_for_hash`]: crate::ln::channelmanager::ChannelManager::create_inbound_payment_for_hash
+ */
+ uint64_t user_payment_id;
+} LDKPaymentPurpose_LDKInvoicePayment_Body;
+
+typedef struct MUST_USE_STRUCT LDKPaymentPurpose {
+ LDKPaymentPurpose_Tag tag;
+ union {
+ LDKPaymentPurpose_LDKInvoicePayment_Body invoice_payment;
+ struct {
+ struct LDKThirtyTwoBytes spontaneous_payment;
+ };
+ };
+} LDKPaymentPurpose;
+
+/**
+ * The reason the channel was closed. See individual variants more details.
+ */
+typedef enum LDKClosureReason_Tag {
+ /**
+ * Closure generated from receiving a peer error message.
+ *
+ * Our counterparty may have broadcasted their latest commitment state, and we have
+ * as well.
+ */
+ LDKClosureReason_CounterpartyForceClosed,
+ /**
+ * Closure generated from [`ChannelManager::force_close_channel`], called by the user.
+ *
+ * [`ChannelManager::force_close_channel`]: crate::ln::channelmanager::ChannelManager::force_close_channel.
+ */
+ LDKClosureReason_HolderForceClosed,
+ /**
+ * The channel was closed after negotiating a cooperative close and we've now broadcasted
+ * the cooperative close transaction. Note the shutdown may have been initiated by us.
+ */
+ LDKClosureReason_CooperativeClosure,
+ /**
+ * A commitment transaction was confirmed on chain, closing the channel. Most likely this
+ * commitment transaction came from our counterparty, but it may also have come from
+ * a copy of our own `ChannelMonitor`.
+ */
+ LDKClosureReason_CommitmentTxConfirmed,
+ /**
+ * Closure generated from processing an event, likely a HTLC forward/relay/reception.
+ */
+ LDKClosureReason_ProcessingError,
+ /**
+ * The `PeerManager` informed us that we've disconnected from the peer. We close channels
+ * if the `PeerManager` informed us that it is unlikely we'll be able to connect to the
+ * peer again in the future or if the peer disconnected before we finished negotiating
+ * the channel open. The first case may be caused by incompatible features which our
+ * counterparty, or we, require.
+ */
+ LDKClosureReason_DisconnectedPeer,
+ /**
+ * Closure generated from `ChannelManager::read` if the ChannelMonitor is newer than
+ * the ChannelManager deserialized.
+ */
+ LDKClosureReason_OutdatedChannelManager,
+ /**
+ * Must be last for serialization purposes
+ */
+ LDKClosureReason_Sentinel,
+} LDKClosureReason_Tag;
+
+typedef struct LDKClosureReason_LDKCounterpartyForceClosed_Body {
+ /**
+ * The error which the peer sent us.
+ *
+ * The string should be sanitized before it is used (e.g emitted to logs
+ * or printed to stdout). Otherwise, a well crafted error message may exploit
+ * a security vulnerability in the terminal emulator or the logging subsystem.
+ */
+ struct LDKStr peer_msg;
+} LDKClosureReason_LDKCounterpartyForceClosed_Body;
+
+typedef struct LDKClosureReason_LDKProcessingError_Body {
+ /**
+ * A developer-readable error message which we generated.
+ */
+ struct LDKStr err;
+} LDKClosureReason_LDKProcessingError_Body;
+
+typedef struct MUST_USE_STRUCT LDKClosureReason {
+ LDKClosureReason_Tag tag;
+ union {
+ LDKClosureReason_LDKCounterpartyForceClosed_Body counterparty_force_closed;
+ LDKClosureReason_LDKProcessingError_Body processing_error;
+ };
+} LDKClosureReason;
+
+/**
+ * An Event which you should probably take some action in response to.
+ *
+ * Note that while Writeable and Readable are implemented for Event, you probably shouldn't use
+ * them directly as they don't round-trip exactly (for example FundingGenerationReady is never
+ * written as it makes no sense to respond to it after reconnecting to peers).
+ */
+typedef enum LDKEvent_Tag {
+ /**
+ * Used to indicate that the client should generate a funding transaction with the given
+ * parameters and then call ChannelManager::funding_transaction_generated.
+ * Generated in ChannelManager message handling.
+ * Note that *all inputs* in the funding transaction must spend SegWit outputs or your
+ * counterparty can steal your funds!
+ */
+ LDKEvent_FundingGenerationReady,
+ /**
+ * Indicates we've received money! Just gotta dig out that payment preimage and feed it to
+ * ChannelManager::claim_funds to get it....
+ * Note that if the preimage is not known or the amount paid is incorrect, you should call
+ * ChannelManager::fail_htlc_backwards to free up resources for this HTLC and avoid
+ * network congestion.
+ * The amount paid should be considered 'incorrect' when it is less than or more than twice
+ * the amount expected.
+ * If you fail to call either ChannelManager::claim_funds or
+ * ChannelManager::fail_htlc_backwards within the HTLC's timeout, the HTLC will be
+ * automatically failed.
+ */
+ LDKEvent_PaymentReceived,
+ /**
+ * Indicates an outbound payment we made succeeded (i.e. it made it all the way to its target
+ * and we got back the payment preimage for it).
+ *
+ * Note for MPP payments: in rare cases, this event may be preceded by a `PaymentPathFailed`
+ * event. In this situation, you SHOULD treat this payment as having succeeded.
+ */
+ LDKEvent_PaymentSent,
+ /**
+ * Indicates an outbound payment we made failed. Probably some intermediary node dropped
+ * something. You may wish to retry with a different route.
+ */
+ LDKEvent_PaymentPathFailed,
+ /**
+ * Used to indicate that ChannelManager::process_pending_htlc_forwards should be called at a
+ * time in the future.
+ */