-typedef struct LDKCResultTempl_TxOut__AccessError {
- LDKCResultPtr_TxOut__AccessError contents;
- bool result_ok;
-} LDKCResultTempl_TxOut__AccessError;
-
-typedef LDKCResultTempl_TxOut__AccessError LDKCResult_TxOutAccessErrorZ;
-
-/**
- * The `Access` trait defines behavior for accessing chain data and state, such as blocks and
- * UTXOs.
- */
-typedef struct LDKAccess {
- void *this_arg;
- /**
- * Returns the transaction output of a funding transaction encoded by [`short_channel_id`].
- * Returns an error if `genesis_hash` is for a different chain or if such a transaction output
- * is unknown.
- *
- * [`short_channel_id`]: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#definition-of-short_channel_id
- */
- LDKCResult_TxOutAccessErrorZ (*get_utxo)(const void *this_arg, const uint8_t (*genesis_hash)[32], uint64_t short_channel_id);
- void (*free)(void *this_arg);
-} LDKAccess;
-
-
-
-/**
- * One counterparty's public keys which do not change over the life of a channel.
- */
-typedef struct MUST_USE_STRUCT LDKChannelPublicKeys {
- /**
- * 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.
- */
- LDKnativeChannelPublicKeys *inner;
- bool is_owned;
-} LDKChannelPublicKeys;
-
-
-
-/**
- * The per-commitment point and a set of pre-calculated public keys used for transaction creation
- * in the signer.
- * The pre-calculated keys are an optimization, because ChannelKeys has enough
- * information to re-derive them.
- */
-typedef struct MUST_USE_STRUCT LDKPreCalculatedTxCreationKeys {
- /**
- * 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.
- */
- LDKnativePreCalculatedTxCreationKeys *inner;
- bool is_owned;
-} LDKPreCalculatedTxCreationKeys;
-
-typedef struct LDKCVecTempl_HTLCOutputInCommitment {
- LDKHTLCOutputInCommitment *data;
- uintptr_t datalen;
-} LDKCVecTempl_HTLCOutputInCommitment;
-
-typedef LDKCVecTempl_HTLCOutputInCommitment LDKCVec_HTLCOutputInCommitmentZ;
-
-
-
-/**
- * We use this to track holder commitment transactions and put off signing them until we are ready
- * to broadcast. This class can be used inside a signer implementation to generate a signature
- * given the relevant secret key.
- */
-typedef struct MUST_USE_STRUCT LDKHolderCommitmentTransaction {
- /**
- * 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.
- */
- LDKnativeHolderCommitmentTransaction *inner;
- bool is_owned;
-} LDKHolderCommitmentTransaction;
-
-
-
-/**
- * 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;
-
-/**
- * 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.
- */
- 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
- */
- LDKThirtyTwoBytes (*release_commitment_secret)(const void *this_arg, uint64_t idx);
- /**
- * Gets the holder's channel public keys and basepoints
- */
- 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 LDKChannelKeys*);
- /**
- * 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, uint32_t feerate_per_kw, LDKTransaction commitment_tx, const LDKPreCalculatedTxCreationKeys *keys, LDKCVec_HTLCOutputInCommitmentZ htlcs);
- /**
- * Create a signature for a holder's commitment transaction. This will only ever be called with
- * the same holder_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 LDKHolderCommitmentTransaction *holder_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*
- * holder_commitment_tx values. While this will never be called with a revoked
- * holder_commitment_tx, it is possible that it is called with the second-latest
- * holder_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
- * holder_commitment_tx. For those HTLCs which have transaction_output_index set to None
- * (implying they were considered dust at the time the commitment transaction was negotiated),
- * a corresponding None should be included in the return value. All other positions in the
- * return value must contain a signature.
- */
- LDKCResult_CVec_SignatureZNoneZ (*sign_holder_commitment_htlc_transactions)(const void *this_arg, const LDKHolderCommitmentTransaction *holder_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, LDKTransaction justice_tx, uintptr_t input, uint64_t amount, const uint8_t (*per_commitment_key)[32], const LDKHTLCOutputInCommitment *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, LDKTransaction htlc_tx, uintptr_t input, uint64_t amount, LDKPublicKey per_commitment_point, const LDKHTLCOutputInCommitment *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, 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 LDKUnsignedChannelAnnouncement *msg);
- /**
- * Set the counterparty channel basepoints and counterparty_selected/holder_selected_contest_delay.
- * This is done immediately on incoming channels and as soon as the channel is accepted on outgoing channels.
- *
- * We bind holder_selected_contest_delay late here for API convenience.
- *
- * Will be called before any signatures are applied.
- */
- void (*on_accept)(void *this_arg, const LDKChannelPublicKeys *channel_points, uint16_t counterparty_selected_contest_delay, uint16_t holder_selected_contest_delay);
- void *(*clone)(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.
- */
-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;
-
-
-
-/**
- * An update generated by the underlying Channel itself which contains some new information the
- * ChannelMonitor should be made aware of.
- */
-typedef struct MUST_USE_STRUCT LDKChannelMonitorUpdate {
- /**
- * 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.
- */
- LDKnativeChannelMonitorUpdate *inner;
- bool is_owned;
-} LDKChannelMonitorUpdate;
-
-
-
-/**
- * An event to be processed by the ChannelManager.
- */
-typedef struct MUST_USE_STRUCT LDKMonitorEvent {
- /**
- * 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.
- */
- LDKnativeMonitorEvent *inner;
- bool is_owned;
-} LDKMonitorEvent;
-
-typedef struct LDKCVecTempl_MonitorEvent {
- LDKMonitorEvent *data;
- uintptr_t datalen;
-} LDKCVecTempl_MonitorEvent;
-
-typedef LDKCVecTempl_MonitorEvent LDKCVec_MonitorEventZ;