Struct lightning::ln::channelmanager::ChannelManager
source · pub struct ChannelManager<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,{ /* private fields */ }
Expand description
Manager which keeps track of a number of channels and sends messages to the appropriate channel, also tracking HTLC preimages and forwarding onion packets appropriately.
Implements ChannelMessageHandler
, handling the multi-channel parts and passing things through
to individual Channels.
Implements Writeable
to write out all channel state to disk. Implies peer_disconnected
for
all peers during write/read (though does not modify this instance, only the instance being
serialized). This will result in any channels which have not yet exchanged funding_created
(i.e.,
called funding_transaction_generated
for outbound channels) being closed.
Note that you can be a bit lazier about writing out ChannelManager
than you can be with
ChannelMonitor
. With ChannelMonitor
you MUST write each monitor update out to disk before
returning from chain::Watch::watch_channel
/update_channel
, with ChannelManagers, writing updates
happens out-of-band (and will prevent any other ChannelManager
operations from occurring during
the serialization process). If the deserialized version is out-of-date compared to the
ChannelMonitor
passed by reference to read
, those channels will be force-closed based on the
ChannelMonitor
state and no funds will be lost (mod on-chain transaction fees).
Note that the deserializer is only implemented for (
BlockHash
,
ChannelManager
)
, which
tells you the last block hash which was connected. You should get the best block tip before using the manager.
See chain::Listen
and chain::Confirm
for more details.
Note that ChannelManager
is responsible for tracking liveness of its channels and generating
ChannelUpdate
messages informing peers that the channel is temporarily disabled. To avoid
spam due to quick disconnection/reconnection, updates are not sent until the channel has been
offline for a full minute. In order to track this, you must call
timer_tick_occurred
roughly once per minute, though it doesn’t have to be perfect.
To avoid trivial DoS issues, ChannelManager
limits the number of inbound connections and
inbound channels without confirmed funding transactions. This may result in nodes which we do
not have a channel with being unable to connect to us or open new channels with us if we have
many peers with unfunded channels.
Because it is an indication of trust, inbound channels which we’ve accepted as 0conf are exempted from the count of unfunded channels. Similarly, outbound channels and connections are never limited. Please ensure you limit the count of such channels yourself.
Rather than using a plain ChannelManager
, it is preferable to use either a SimpleArcChannelManager
a SimpleRefChannelManager
, for conciseness. See their documentation for more details, but
essentially you should default to using a SimpleRefChannelManager
, and use a
SimpleArcChannelManager
when you require a ChannelManager
with a static lifetime, such as when
you’re using lightning-net-tokio.
Implementations§
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
sourcepub fn new(
fee_est: F,
chain_monitor: M,
tx_broadcaster: T,
router: R,
logger: L,
entropy_source: ES,
node_signer: NS,
signer_provider: SP,
config: UserConfig,
params: ChainParameters
) -> Self
pub fn new( fee_est: F, chain_monitor: M, tx_broadcaster: T, router: R, logger: L, entropy_source: ES, node_signer: NS, signer_provider: SP, config: UserConfig, params: ChainParameters ) -> Self
Constructs a new ChannelManager
to hold several channels and route between them.
This is the main “logic hub” for all channel-related actions, and implements
ChannelMessageHandler
.
Non-proportional fees are fixed according to our risk using the provided fee estimator.
Users need to notify the new ChannelManager
when a new block is connected or
disconnected using its block_connected
and block_disconnected
methods, starting
from after params.best_block.block_hash
. See chain::Listen
and chain::Confirm
for
more details.
sourcepub fn get_current_default_configuration(&self) -> &UserConfig
pub fn get_current_default_configuration(&self) -> &UserConfig
Gets the current configuration applied to all new channels.
sourcepub fn create_channel(
&self,
their_network_key: PublicKey,
channel_value_satoshis: u64,
push_msat: u64,
user_channel_id: u128,
override_config: Option<UserConfig>
) -> Result<[u8; 32], APIError>
pub fn create_channel( &self, their_network_key: PublicKey, channel_value_satoshis: u64, push_msat: u64, user_channel_id: u128, override_config: Option<UserConfig> ) -> Result<[u8; 32], APIError>
Creates a new outbound channel to the given remote node and with the given value.
user_channel_id
will be provided back as in
Event::FundingGenerationReady::user_channel_id
to allow tracking of which events
correspond with which create_channel
call. Note that the user_channel_id
defaults to a
randomized value for inbound channels. user_channel_id
has no meaning inside of LDK, it
is simply copied to events and otherwise ignored.
Raises APIError::APIMisuseError
when channel_value_satoshis
> 2**24 or push_msat
is
greater than channel_value_satoshis * 1k
or channel_value_satoshis < 1000
.
Note that we do not check if you are currently connected to the given peer. If no
connection is available, the outbound open_channel
message may fail to send, resulting in
the channel eventually being silently forgotten (dropped on reload).
Returns the new Channel’s temporary channel_id
. This ID will appear as
Event::FundingGenerationReady::temporary_channel_id
and in
ChannelDetails::channel_id
until after
ChannelManager::funding_transaction_generated
is called, swapping the Channel’s ID for
one derived from the funding transaction’s TXID. If the counterparty rejects the channel
immediately, this temporary ID will appear in Event::ChannelClosed::channel_id
.
sourcepub fn list_channels(&self) -> Vec<ChannelDetails>
pub fn list_channels(&self) -> Vec<ChannelDetails>
Gets the list of open channels, in random order. See ChannelDetails
field documentation for
more information.
sourcepub fn list_usable_channels(&self) -> Vec<ChannelDetails>
pub fn list_usable_channels(&self) -> Vec<ChannelDetails>
Gets the list of usable channels, in random order. Useful as an argument to
Router::find_route
to ensure non-announced channels are used.
These are guaranteed to have their ChannelDetails::is_usable
value set to true, see the
documentation for ChannelDetails::is_usable
for more info on exactly what the criteria
are.
sourcepub fn list_channels_with_counterparty(
&self,
counterparty_node_id: &PublicKey
) -> Vec<ChannelDetails>
pub fn list_channels_with_counterparty( &self, counterparty_node_id: &PublicKey ) -> Vec<ChannelDetails>
Gets the list of channels we have with a given counterparty, in random order.
sourcepub fn list_recent_payments(&self) -> Vec<RecentPaymentDetails>
pub fn list_recent_payments(&self) -> Vec<RecentPaymentDetails>
Returns in an undefined order recent payments that – if not fulfilled – have yet to find a successful path, or have unresolved HTLCs.
This can be useful for payments that may have been prepared, but ultimately not sent, as a
result of a crash. If such a payment exists, is not listed here, and an
Event::PaymentSent
has not been received, you may consider resending the payment.
sourcepub fn close_channel(
&self,
channel_id: &[u8; 32],
counterparty_node_id: &PublicKey
) -> Result<(), APIError>
pub fn close_channel( &self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey ) -> Result<(), APIError>
Begins the process of closing a channel. After this call (plus some timeout), no new HTLCs will be accepted on the given channel, and after additional timeout/the closing of all pending HTLCs, the channel will be closed on chain.
- If we are the channel initiator, we will pay between our
Background
andChannelConfig::force_close_avoidance_max_fee_satoshis
plus ourNormal
fee estimate. - If our counterparty is the channel initiator, we will require a channel closing
transaction feerate of at least our
Background
feerate or the feerate which would appear on a force-closure transaction, whichever is lower. We will allow our counterparty to pay as much fee as they’d like, however.
May generate a SendShutdown
message event on success, which should be relayed.
sourcepub fn close_channel_with_target_feerate(
&self,
channel_id: &[u8; 32],
counterparty_node_id: &PublicKey,
target_feerate_sats_per_1000_weight: u32
) -> Result<(), APIError>
pub fn close_channel_with_target_feerate( &self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey, target_feerate_sats_per_1000_weight: u32 ) -> Result<(), APIError>
Begins the process of closing a channel. After this call (plus some timeout), no new HTLCs will be accepted on the given channel, and after additional timeout/the closing of all pending HTLCs, the channel will be closed on chain.
target_feerate_sat_per_1000_weight
has different meanings depending on if we initiated
the channel being closed or not:
- If we are the channel initiator, we will pay at least this feerate on the closing
transaction. The upper-bound is set by
ChannelConfig::force_close_avoidance_max_fee_satoshis
plus ourNormal
fee estimate (ortarget_feerate_sat_per_1000_weight
, if it is greater). - If our counterparty is the channel initiator, we will refuse to accept a channel closure
transaction feerate below
target_feerate_sat_per_1000_weight
(or the feerate which will appear on a force-closure transaction, whichever is lower).
May generate a SendShutdown
message event on success, which should be relayed.
sourcepub fn force_close_broadcasting_latest_txn(
&self,
channel_id: &[u8; 32],
counterparty_node_id: &PublicKey
) -> Result<(), APIError>
pub fn force_close_broadcasting_latest_txn( &self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey ) -> Result<(), APIError>
Force closes a channel, immediately broadcasting the latest local transaction(s) and
rejecting new HTLCs on the given channel. Fails if channel_id
is unknown to
the manager, or if the counterparty_node_id
isn’t the counterparty of the corresponding
channel.
sourcepub fn force_close_without_broadcasting_txn(
&self,
channel_id: &[u8; 32],
counterparty_node_id: &PublicKey
) -> Result<(), APIError>
pub fn force_close_without_broadcasting_txn( &self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey ) -> Result<(), APIError>
Force closes a channel, rejecting new HTLCs on the given channel but skips broadcasting
the latest local transaction(s). Fails if channel_id
is unknown to the manager, or if the
counterparty_node_id
isn’t the counterparty of the corresponding channel.
You can always get the latest local transaction(s) to broadcast from
ChannelMonitor::get_latest_holder_commitment_txn
.
sourcepub fn force_close_all_channels_broadcasting_latest_txn(&self)
pub fn force_close_all_channels_broadcasting_latest_txn(&self)
Force close all channels, immediately broadcasting the latest local commitment transaction for each to the chain and rejecting new HTLCs on each.
sourcepub fn force_close_all_channels_without_broadcasting_txn(&self)
pub fn force_close_all_channels_without_broadcasting_txn(&self)
Force close all channels rejecting new HTLCs on each but without broadcasting the latest local transaction(s).
sourcepub fn send_payment_with_route(
&self,
route: &Route,
payment_hash: PaymentHash,
recipient_onion: RecipientOnionFields,
payment_id: PaymentId
) -> Result<(), PaymentSendFailure>
pub fn send_payment_with_route( &self, route: &Route, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId ) -> Result<(), PaymentSendFailure>
Sends a payment along a given route.
Value parameters are provided via the last hop in route, see documentation for RouteHop
fields for more info.
May generate UpdateHTLCs
message(s) event on success, which should be relayed (e.g. via
PeerManager::process_events
).
Avoiding Duplicate Payments
If a pending payment is currently in-flight with the same PaymentId
provided, this
method will error with an APIError::InvalidRoute
. Note, however, that once a payment
is no longer pending (either via ChannelManager::abandon_payment
, or handling of an
Event::PaymentSent
or Event::PaymentFailed
) LDK will not stop you from sending a
second payment with the same PaymentId
.
Thus, in order to ensure duplicate payments are not sent, you should implement your own
tracking of payments, including state to indicate once a payment has completed. Because you
should also ensure that PaymentHash
es are not re-used, for simplicity, you should
consider using the PaymentHash
as the key for tracking payments. In that case, the
PaymentId
should be a copy of the PaymentHash
bytes.
Additionally, in the scenario where we begin the process of sending a payment, but crash
before send_payment
returns (or prior to ChannelMonitorUpdate
persistence if you’re
using ChannelMonitorUpdateStatus::InProgress
), the payment may be lost on restart. See
ChannelManager::list_recent_payments
for more information.
Possible Error States on PaymentSendFailure
Each path may have a different return value, and PaymentSendFailure
may return a Vec
with
each entry matching the corresponding-index entry in the route paths, see
PaymentSendFailure
for more info.
In general, a path may raise:
APIError::InvalidRoute
when an invalid route or forwarding parameter (cltv_delta, fee, node public key) is specified.APIError::ChannelUnavailable
if the next-hop channel is not available for updates (including due to previous monitor update failure or new permanent monitor update failure).APIError::MonitorUpdateInProgress
if a new monitor update failure prevented sending the relevant updates.
Note that depending on the type of the PaymentSendFailure
the HTLC may have been
irrevocably committed to on our end. In such a case, do NOT retry the payment with a
different route unless you intend to pay twice!
sourcepub fn send_payment(
&self,
payment_hash: PaymentHash,
recipient_onion: RecipientOnionFields,
payment_id: PaymentId,
route_params: RouteParameters,
retry_strategy: Retry
) -> Result<(), RetryableSendFailure>
pub fn send_payment( &self, payment_hash: PaymentHash, recipient_onion: RecipientOnionFields, payment_id: PaymentId, route_params: RouteParameters, retry_strategy: Retry ) -> Result<(), RetryableSendFailure>
Similar to ChannelManager::send_payment
, but will automatically find a route based on
route_params
and retry failed payment paths based on retry_strategy
.
sourcepub fn abandon_payment(&self, payment_id: PaymentId)
pub fn abandon_payment(&self, payment_id: PaymentId)
Signals that no further retries for the given payment should occur. Useful if you have a pending outbound payment with retries remaining, but wish to stop retrying the payment before retries are exhausted.
If no Event::PaymentFailed
event had been generated before, one will be generated as soon
as there are no remaining pending HTLCs for this payment.
Note that calling this method does not prevent a payment from succeeding. You must still
wait until you receive either a Event::PaymentFailed
or Event::PaymentSent
event to
determine the ultimate status of a payment.
If an Event::PaymentFailed
event is generated and we restart without this
ChannelManager
having been persisted, another Event::PaymentFailed
may be generated.
sourcepub fn send_spontaneous_payment(
&self,
route: &Route,
payment_preimage: Option<PaymentPreimage>,
recipient_onion: RecipientOnionFields,
payment_id: PaymentId
) -> Result<PaymentHash, PaymentSendFailure>
pub fn send_spontaneous_payment( &self, route: &Route, payment_preimage: Option<PaymentPreimage>, recipient_onion: RecipientOnionFields, payment_id: PaymentId ) -> Result<PaymentHash, PaymentSendFailure>
Send a spontaneous payment, which is a payment that does not require the recipient to have generated an invoice. Optionally, you may specify the preimage. If you do choose to specify the preimage, it must be a cryptographically secure random value that no intermediate node would be able to guess – otherwise, an intermediate node may claim the payment and it will never reach the recipient.
See send_payment
documentation for more details on the return value of this function
and idempotency guarantees provided by the PaymentId
key.
Similar to regular payments, you MUST NOT reuse a payment_preimage
value. See
send_payment
for more information about the risks of duplicate preimage usage.
Note that route
must have exactly one path.
sourcepub fn send_spontaneous_payment_with_retry(
&self,
payment_preimage: Option<PaymentPreimage>,
recipient_onion: RecipientOnionFields,
payment_id: PaymentId,
route_params: RouteParameters,
retry_strategy: Retry
) -> Result<PaymentHash, RetryableSendFailure>
pub fn send_spontaneous_payment_with_retry( &self, payment_preimage: Option<PaymentPreimage>, recipient_onion: RecipientOnionFields, payment_id: PaymentId, route_params: RouteParameters, retry_strategy: Retry ) -> Result<PaymentHash, RetryableSendFailure>
Similar to ChannelManager::send_spontaneous_payment
, but will automatically find a route
based on route_params
and retry failed payment paths based on retry_strategy
.
See PaymentParameters::for_keysend
for help in constructing route_params
for spontaneous
payments.
sourcepub fn send_probe(
&self,
path: Path
) -> Result<(PaymentHash, PaymentId), PaymentSendFailure>
pub fn send_probe( &self, path: Path ) -> Result<(PaymentHash, PaymentId), PaymentSendFailure>
Send a payment that is probing the given route for liquidity. We calculate the
PaymentHash
of probes based on a static secret and a random PaymentId
, which allows
us to easily discern them from real payments.
sourcepub fn funding_transaction_generated(
&self,
temporary_channel_id: &[u8; 32],
counterparty_node_id: &PublicKey,
funding_transaction: Transaction
) -> Result<(), APIError>
pub fn funding_transaction_generated( &self, temporary_channel_id: &[u8; 32], counterparty_node_id: &PublicKey, funding_transaction: Transaction ) -> Result<(), APIError>
Call this upon creation of a funding transaction for the given channel.
Returns an APIError::APIMisuseError
if the funding_transaction spent non-SegWit outputs
or if no output was found which matches the parameters in Event::FundingGenerationReady
.
Returns APIError::APIMisuseError
if the funding transaction is not final for propagation
across the p2p network.
Returns APIError::ChannelUnavailable
if a funding transaction has already been provided
for the channel or if the channel has been closed as indicated by Event::ChannelClosed
.
May panic if the output found in the funding transaction is duplicative with some other channel (note that this should be trivially prevented by using unique funding transaction keys per-channel).
Do NOT broadcast the funding transaction yourself. When we have safely received our
counterparty’s signature the funding transaction will automatically be broadcast via the
BroadcasterInterface
provided when this ChannelManager
was constructed.
Note that this includes RBF or similar transaction replacement strategies - lightning does not currently support replacing a funding transaction on an existing channel. Instead, create a new channel with a conflicting funding transaction.
Note to keep the miner incentives aligned in moving the blockchain forward, we recommend the wallet software generating the funding transaction to apply anti-fee sniping as implemented by Bitcoin Core wallet. See https://bitcoinops.org/en/topics/fee-sniping/ for more details.
sourcepub fn update_channel_config(
&self,
counterparty_node_id: &PublicKey,
channel_ids: &[[u8; 32]],
config: &ChannelConfig
) -> Result<(), APIError>
pub fn update_channel_config( &self, counterparty_node_id: &PublicKey, channel_ids: &[[u8; 32]], config: &ChannelConfig ) -> Result<(), APIError>
Atomically updates the ChannelConfig
for the given channels.
Once the updates are applied, each eligible channel (advertised with a known short channel
ID and a change in forwarding_fee_proportional_millionths
, forwarding_fee_base_msat
,
or cltv_expiry_delta
) has a BroadcastChannelUpdate
event message generated
containing the new ChannelUpdate
message which should be broadcast to the network.
Returns ChannelUnavailable
when a channel is not found or an incorrect
counterparty_node_id
is provided.
Returns APIMisuseError
when a cltv_expiry_delta
update is to be applied with a value
below MIN_CLTV_EXPIRY_DELTA
.
If an error is returned, none of the updates should be considered applied.
sourcepub fn forward_intercepted_htlc(
&self,
intercept_id: InterceptId,
next_hop_channel_id: &[u8; 32],
next_node_id: PublicKey,
amt_to_forward_msat: u64
) -> Result<(), APIError>
pub fn forward_intercepted_htlc( &self, intercept_id: InterceptId, next_hop_channel_id: &[u8; 32], next_node_id: PublicKey, amt_to_forward_msat: u64 ) -> Result<(), APIError>
Attempts to forward an intercepted HTLC over the provided channel id and with the provided
amount to forward. Should only be called in response to an HTLCIntercepted
event.
Intercepted HTLCs can be useful for Lightning Service Providers (LSPs) to open a just-in-time channel to a receiving node if the node lacks sufficient inbound liquidity.
To make use of intercepted HTLCs, set UserConfig::accept_intercept_htlcs
and use
ChannelManager::get_intercept_scid
to generate short channel id(s) to put in the
receiver’s invoice route hints. These route hints will signal to LDK to generate an
HTLCIntercepted
event when it receives the forwarded HTLC, and this method or
ChannelManager::fail_intercepted_htlc
MUST be called in response to the event.
Note that LDK does not enforce fee requirements in amt_to_forward_msat
, and will not stop
you from forwarding more than you received.
Errors if the event was not handled in time, in which case the HTLC was automatically failed backwards.
sourcepub fn fail_intercepted_htlc(
&self,
intercept_id: InterceptId
) -> Result<(), APIError>
pub fn fail_intercepted_htlc( &self, intercept_id: InterceptId ) -> Result<(), APIError>
Fails the intercepted HTLC indicated by intercept_id. Should only be called in response to
an HTLCIntercepted
event. See ChannelManager::forward_intercepted_htlc
.
Errors if the event was not handled in time, in which case the HTLC was automatically failed backwards.
sourcepub fn process_pending_htlc_forwards(&self)
pub fn process_pending_htlc_forwards(&self)
Processes HTLCs which are pending waiting on random forward delay.
Should only really ever be called in response to a PendingHTLCsForwardable event. Will likely generate further events.
sourcepub fn timer_tick_occurred(&self)
pub fn timer_tick_occurred(&self)
Performs actions which should happen on startup and roughly once per minute thereafter.
This currently includes:
- Increasing or decreasing the on-chain feerate estimates for our outbound channels,
- Broadcasting
ChannelUpdate
messages if we’ve been disconnected from our peer for more than a minute, informing the network that they should no longer attempt to route over the channel. - Expiring a channel’s previous
ChannelConfig
if necessary to only allow forwarding HTLCs with the currentChannelConfig
. - Removing peers which have disconnected but and no longer have any channels.
Note that this may cause reentrancy through chain::Watch::update_channel
calls or feerate
estimate fetches.
sourcepub fn fail_htlc_backwards(&self, payment_hash: &PaymentHash)
pub fn fail_htlc_backwards(&self, payment_hash: &PaymentHash)
Indicates that the preimage for payment_hash is unknown or the received amount is incorrect after a PaymentClaimable event, failing the HTLC back to its origin and freeing resources along the path (including in our own channel on which we received it).
Note that in some cases around unclean shutdown, it is possible the payment may have
already been claimed by you via ChannelManager::claim_funds
prior to you seeing (a
second copy of) the events::Event::PaymentClaimable
event. Alternatively, the payment
may have already been failed automatically by LDK if it was nearing its expiration time.
While LDK will never claim a payment automatically on your behalf (i.e. without you calling
ChannelManager::claim_funds
), you should still monitor for
events::Event::PaymentClaimed
events even for payments you intend to fail, especially on
startup during which time claims that were in-progress at shutdown may be replayed.
sourcepub fn fail_htlc_backwards_with_reason(
&self,
payment_hash: &PaymentHash,
failure_code: FailureCode
)
pub fn fail_htlc_backwards_with_reason( &self, payment_hash: &PaymentHash, failure_code: FailureCode )
This is a variant of ChannelManager::fail_htlc_backwards
that allows you to specify the
reason for the failure.
See FailureCode
for valid failure codes.
sourcepub fn claim_funds(&self, payment_preimage: PaymentPreimage)
pub fn claim_funds(&self, payment_preimage: PaymentPreimage)
Provides a payment preimage in response to Event::PaymentClaimable
, generating any
MessageSendEvent
s needed to claim the payment.
This method is guaranteed to ensure the payment has been claimed but only if the current
height is strictly below Event::PaymentClaimable::claim_deadline
. To avoid race
conditions, you should wait for an Event::PaymentClaimed
before considering the payment
successful. It will generally be available in the next process_pending_events
call.
Note that if you did not set an amount_msat
when calling create_inbound_payment
or
create_inbound_payment_for_hash
you must check that the amount in the PaymentClaimable
event matches your expectation. If you fail to do so and call this method, you may provide
the sender “proof-of-payment” when they did not fulfill the full expected payment.
sourcepub fn get_our_node_id(&self) -> PublicKey
pub fn get_our_node_id(&self) -> PublicKey
Gets the node_id held by this ChannelManager
sourcepub fn accept_inbound_channel(
&self,
temporary_channel_id: &[u8; 32],
counterparty_node_id: &PublicKey,
user_channel_id: u128
) -> Result<(), APIError>
pub fn accept_inbound_channel( &self, temporary_channel_id: &[u8; 32], counterparty_node_id: &PublicKey, user_channel_id: u128 ) -> Result<(), APIError>
Accepts a request to open a channel after a Event::OpenChannelRequest
.
The temporary_channel_id
parameter indicates which inbound channel should be accepted,
and the counterparty_node_id
parameter is the id of the peer which has requested to open
the channel.
The user_channel_id
parameter will be provided back in
Event::ChannelClosed::user_channel_id
to allow tracking of which events correspond
with which accept_inbound_channel
/accept_inbound_channel_from_trusted_peer_0conf
call.
Note that this method will return an error and reject the channel, if it requires support
for zero confirmations. Instead, accept_inbound_channel_from_trusted_peer_0conf
must be
used to accept such channels.
sourcepub fn accept_inbound_channel_from_trusted_peer_0conf(
&self,
temporary_channel_id: &[u8; 32],
counterparty_node_id: &PublicKey,
user_channel_id: u128
) -> Result<(), APIError>
pub fn accept_inbound_channel_from_trusted_peer_0conf( &self, temporary_channel_id: &[u8; 32], counterparty_node_id: &PublicKey, user_channel_id: u128 ) -> Result<(), APIError>
Accepts a request to open a channel after a events::Event::OpenChannelRequest
, treating
it as confirmed immediately.
The user_channel_id
parameter will be provided back in
Event::ChannelClosed::user_channel_id
to allow tracking of which events correspond
with which accept_inbound_channel
/accept_inbound_channel_from_trusted_peer_0conf
call.
Unlike ChannelManager::accept_inbound_channel
, this method accepts the incoming channel
and (if the counterparty agrees), enables forwarding of payments immediately.
This fully trusts that the counterparty has honestly and correctly constructed the funding transaction and blindly assumes that it will eventually confirm.
If it does not confirm before we decide to close the channel, or if the funding transaction does not pay to the correct script the correct amount, you will lose funds.
sourcepub fn create_inbound_payment(
&self,
min_value_msat: Option<u64>,
invoice_expiry_delta_secs: u32,
min_final_cltv_expiry_delta: Option<u16>
) -> Result<(PaymentHash, PaymentSecret), ()>
pub fn create_inbound_payment( &self, min_value_msat: Option<u64>, invoice_expiry_delta_secs: u32, min_final_cltv_expiry_delta: Option<u16> ) -> Result<(PaymentHash, PaymentSecret), ()>
Gets a payment secret and payment hash for use in an invoice given to a third party wishing to pay us.
This differs from create_inbound_payment_for_hash
only in that it generates the
PaymentHash
and PaymentPreimage
for you.
The PaymentPreimage
will ultimately be returned to you in the PaymentClaimable
, which
will have the PaymentClaimable::purpose
be PaymentPurpose::InvoicePayment
with
its PaymentPurpose::InvoicePayment::payment_preimage
field filled in. That should then be
passed directly to claim_funds
.
See create_inbound_payment_for_hash
for detailed documentation on behavior and requirements.
Note that a malicious eavesdropper can intuit whether an inbound payment was created by
create_inbound_payment
or create_inbound_payment_for_hash
based on runtime.
Note
If you register an inbound payment with this method, then serialize the ChannelManager
, then
deserialize it with a node running 0.0.103 and earlier, the payment will fail to be received.
Errors if min_value_msat
is greater than total bitcoin supply.
If min_final_cltv_expiry_delta
is set to some value, then the payment will not be receivable
on versions of LDK prior to 0.0.114.
sourcepub fn create_inbound_payment_legacy(
&self,
min_value_msat: Option<u64>,
invoice_expiry_delta_secs: u32
) -> Result<(PaymentHash, PaymentSecret), APIError>
👎Deprecated
pub fn create_inbound_payment_legacy( &self, min_value_msat: Option<u64>, invoice_expiry_delta_secs: u32 ) -> Result<(PaymentHash, PaymentSecret), APIError>
Legacy version of create_inbound_payment
. Use this method if you wish to share
serialized state with LDK node(s) running 0.0.103 and earlier.
May panic if invoice_expiry_delta_secs
is greater than one year.
Note
This method is deprecated and will be removed soon.
sourcepub fn create_inbound_payment_for_hash(
&self,
payment_hash: PaymentHash,
min_value_msat: Option<u64>,
invoice_expiry_delta_secs: u32,
min_final_cltv_expiry: Option<u16>
) -> Result<PaymentSecret, ()>
pub fn create_inbound_payment_for_hash( &self, payment_hash: PaymentHash, min_value_msat: Option<u64>, invoice_expiry_delta_secs: u32, min_final_cltv_expiry: Option<u16> ) -> Result<PaymentSecret, ()>
Gets a PaymentSecret
for a given PaymentHash
, for which the payment preimage is
stored external to LDK.
A PaymentClaimable
event will only be generated if the PaymentSecret
matches a
payment secret fetched via this method or create_inbound_payment
, and which is at least
the min_value_msat
provided here, if one is provided.
The PaymentHash
(and corresponding PaymentPreimage
) should be globally unique, though
note that LDK will not stop you from registering duplicate payment hashes for inbound
payments.
min_value_msat
should be set if the invoice being generated contains a value. Any payment
received for the returned PaymentHash
will be required to be at least min_value_msat
before a PaymentClaimable
event will be generated, ensuring that we do not provide the
sender “proof-of-payment” unless they have paid the required amount.
invoice_expiry_delta_secs
describes the number of seconds that the invoice is valid for
in excess of the current time. This should roughly match the expiry time set in the invoice.
After this many seconds, we will remove the inbound payment, resulting in any attempts to
pay the invoice failing. The BOLT spec suggests 3,600 secs as a default validity time for
invoices when no timeout is set.
Note that we use block header time to time-out pending inbound payments (with some margin
to compensate for the inaccuracy of block header timestamps). Thus, in practice we will
accept a payment and generate a PaymentClaimable
event for some time after the expiry.
If you need exact expiry semantics, you should enforce them upon receipt of
PaymentClaimable
.
Note that invoices generated for inbound payments should have their min_final_cltv_expiry_delta
set to at least MIN_FINAL_CLTV_EXPIRY_DELTA
.
Note that a malicious eavesdropper can intuit whether an inbound payment was created by
create_inbound_payment
or create_inbound_payment_for_hash
based on runtime.
Note
If you register an inbound payment with this method, then serialize the ChannelManager
, then
deserialize it with a node running 0.0.103 and earlier, the payment will fail to be received.
Errors if min_value_msat
is greater than total bitcoin supply.
If min_final_cltv_expiry_delta
is set to some value, then the payment will not be receivable
on versions of LDK prior to 0.0.114.
sourcepub fn create_inbound_payment_for_hash_legacy(
&self,
payment_hash: PaymentHash,
min_value_msat: Option<u64>,
invoice_expiry_delta_secs: u32
) -> Result<PaymentSecret, APIError>
👎Deprecated
pub fn create_inbound_payment_for_hash_legacy( &self, payment_hash: PaymentHash, min_value_msat: Option<u64>, invoice_expiry_delta_secs: u32 ) -> Result<PaymentSecret, APIError>
Legacy version of create_inbound_payment_for_hash
. Use this method if you wish to share
serialized state with LDK node(s) running 0.0.103 and earlier.
May panic if invoice_expiry_delta_secs
is greater than one year.
Note
This method is deprecated and will be removed soon.
sourcepub fn get_payment_preimage(
&self,
payment_hash: PaymentHash,
payment_secret: PaymentSecret
) -> Result<PaymentPreimage, APIError>
pub fn get_payment_preimage( &self, payment_hash: PaymentHash, payment_secret: PaymentSecret ) -> Result<PaymentPreimage, APIError>
Gets an LDK-generated payment preimage from a payment hash and payment secret that were
previously returned from create_inbound_payment
.
sourcepub fn get_phantom_scid(&self) -> u64
pub fn get_phantom_scid(&self) -> u64
Gets a fake short channel id for use in receiving phantom node payments. These fake scids are used when constructing the phantom invoice’s route hints.
sourcepub fn get_phantom_route_hints(&self) -> PhantomRouteHints
pub fn get_phantom_route_hints(&self) -> PhantomRouteHints
Gets route hints for use in receiving phantom node payments.
sourcepub fn get_intercept_scid(&self) -> u64
pub fn get_intercept_scid(&self) -> u64
Gets a fake short channel id for use in receiving intercepted payments. These fake scids are
used when constructing the route hints for HTLCs intended to be intercepted. See
ChannelManager::forward_intercepted_htlc
.
Note that this method is not guaranteed to return unique values, you may need to call it a few times to get a unique scid.
sourcepub fn compute_inflight_htlcs(&self) -> InFlightHtlcs
pub fn compute_inflight_htlcs(&self) -> InFlightHtlcs
Gets inflight HTLC information by processing pending outbound payments that are in our channels. May be used during pathfinding to account for in-use channel liquidity.
sourcepub async fn process_pending_events_async<Future: Future, H: Fn(Event) -> Future>(
&self,
handler: H
)
pub async fn process_pending_events_async<Future: Future, H: Fn(Event) -> Future>( &self, handler: H )
Processes any events asynchronously in the order they were generated since the last call using the given event handler.
See the trait-level documentation of EventsProvider
for requirements.
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
sourcepub fn get_persistable_update_future(&self) -> Future ⓘ
pub fn get_persistable_update_future(&self) -> Future ⓘ
Gets a Future
that completes when this ChannelManager
needs to be persisted.
Note that callbacks registered on the Future
MUST NOT call back into this
ChannelManager
and should instead register actions to be taken later.
sourcepub fn current_best_block(&self) -> BestBlock
pub fn current_best_block(&self) -> BestBlock
Gets the latest best block which was connected either via the chain::Listen
or
chain::Confirm
interfaces.
sourcepub fn node_features(&self) -> NodeFeatures
pub fn node_features(&self) -> NodeFeatures
Fetches the set of NodeFeatures
flags which are provided by or required by
ChannelManager
.
sourcepub fn channel_features(&self) -> ChannelFeatures
pub fn channel_features(&self) -> ChannelFeatures
Fetches the set of ChannelFeatures
flags which are provided by or required by
ChannelManager
.
sourcepub fn channel_type_features(&self) -> ChannelTypeFeatures
pub fn channel_type_features(&self) -> ChannelTypeFeatures
Fetches the set of ChannelTypeFeatures
flags which are provided by or required by
ChannelManager
.
sourcepub fn init_features(&self) -> InitFeatures
pub fn init_features(&self) -> InitFeatures
Fetches the set of InitFeatures
flags which are provided by or required by
ChannelManager
.
Trait Implementations§
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelMessageHandler for ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> ChannelMessageHandler for ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
source§fn handle_open_channel(
&self,
counterparty_node_id: &PublicKey,
msg: &OpenChannel
)
fn handle_open_channel( &self, counterparty_node_id: &PublicKey, msg: &OpenChannel )
open_channel
message from the given peer.source§fn handle_accept_channel(
&self,
counterparty_node_id: &PublicKey,
msg: &AcceptChannel
)
fn handle_accept_channel( &self, counterparty_node_id: &PublicKey, msg: &AcceptChannel )
accept_channel
message from the given peer.source§fn handle_funding_created(
&self,
counterparty_node_id: &PublicKey,
msg: &FundingCreated
)
fn handle_funding_created( &self, counterparty_node_id: &PublicKey, msg: &FundingCreated )
funding_created
message from the given peer.source§fn handle_funding_signed(
&self,
counterparty_node_id: &PublicKey,
msg: &FundingSigned
)
fn handle_funding_signed( &self, counterparty_node_id: &PublicKey, msg: &FundingSigned )
funding_signed
message from the given peer.source§fn handle_channel_ready(
&self,
counterparty_node_id: &PublicKey,
msg: &ChannelReady
)
fn handle_channel_ready( &self, counterparty_node_id: &PublicKey, msg: &ChannelReady )
channel_ready
message from the given peer.source§fn handle_shutdown(&self, counterparty_node_id: &PublicKey, msg: &Shutdown)
fn handle_shutdown(&self, counterparty_node_id: &PublicKey, msg: &Shutdown)
shutdown
message from the given peer.source§fn handle_closing_signed(
&self,
counterparty_node_id: &PublicKey,
msg: &ClosingSigned
)
fn handle_closing_signed( &self, counterparty_node_id: &PublicKey, msg: &ClosingSigned )
closing_signed
message from the given peer.source§fn handle_update_add_htlc(
&self,
counterparty_node_id: &PublicKey,
msg: &UpdateAddHTLC
)
fn handle_update_add_htlc( &self, counterparty_node_id: &PublicKey, msg: &UpdateAddHTLC )
update_add_htlc
message from the given peer.source§fn handle_update_fulfill_htlc(
&self,
counterparty_node_id: &PublicKey,
msg: &UpdateFulfillHTLC
)
fn handle_update_fulfill_htlc( &self, counterparty_node_id: &PublicKey, msg: &UpdateFulfillHTLC )
update_fulfill_htlc
message from the given peer.source§fn handle_update_fail_htlc(
&self,
counterparty_node_id: &PublicKey,
msg: &UpdateFailHTLC
)
fn handle_update_fail_htlc( &self, counterparty_node_id: &PublicKey, msg: &UpdateFailHTLC )
update_fail_htlc
message from the given peer.source§fn handle_update_fail_malformed_htlc(
&self,
counterparty_node_id: &PublicKey,
msg: &UpdateFailMalformedHTLC
)
fn handle_update_fail_malformed_htlc( &self, counterparty_node_id: &PublicKey, msg: &UpdateFailMalformedHTLC )
update_fail_malformed_htlc
message from the given peer.source§fn handle_commitment_signed(
&self,
counterparty_node_id: &PublicKey,
msg: &CommitmentSigned
)
fn handle_commitment_signed( &self, counterparty_node_id: &PublicKey, msg: &CommitmentSigned )
commitment_signed
message from the given peer.source§fn handle_revoke_and_ack(
&self,
counterparty_node_id: &PublicKey,
msg: &RevokeAndACK
)
fn handle_revoke_and_ack( &self, counterparty_node_id: &PublicKey, msg: &RevokeAndACK )
revoke_and_ack
message from the given peer.source§fn handle_update_fee(&self, counterparty_node_id: &PublicKey, msg: &UpdateFee)
fn handle_update_fee(&self, counterparty_node_id: &PublicKey, msg: &UpdateFee)
update_fee
message from the given peer.source§fn handle_announcement_signatures(
&self,
counterparty_node_id: &PublicKey,
msg: &AnnouncementSignatures
)
fn handle_announcement_signatures( &self, counterparty_node_id: &PublicKey, msg: &AnnouncementSignatures )
announcement_signatures
message from the given peer.source§fn handle_channel_update(
&self,
counterparty_node_id: &PublicKey,
msg: &ChannelUpdate
)
fn handle_channel_update( &self, counterparty_node_id: &PublicKey, msg: &ChannelUpdate )
channel_update
message from the given peer.source§fn handle_channel_reestablish(
&self,
counterparty_node_id: &PublicKey,
msg: &ChannelReestablish
)
fn handle_channel_reestablish( &self, counterparty_node_id: &PublicKey, msg: &ChannelReestablish )
channel_reestablish
message from the given peer.source§fn peer_disconnected(&self, counterparty_node_id: &PublicKey)
fn peer_disconnected(&self, counterparty_node_id: &PublicKey)
source§fn peer_connected(
&self,
counterparty_node_id: &PublicKey,
init_msg: &Init,
inbound: bool
) -> Result<(), ()>
fn peer_connected( &self, counterparty_node_id: &PublicKey, init_msg: &Init, inbound: bool ) -> Result<(), ()>
channel_reestablish
message(s). Read moresource§fn handle_error(&self, counterparty_node_id: &PublicKey, msg: &ErrorMessage)
fn handle_error(&self, counterparty_node_id: &PublicKey, msg: &ErrorMessage)
error
message from the given peer.source§fn provided_node_features(&self) -> NodeFeatures
fn provided_node_features(&self) -> NodeFeatures
NodeFeatures
which are broadcasted in our NodeAnnouncement
message.source§fn provided_init_features(
&self,
_their_init_features: &PublicKey
) -> InitFeatures
fn provided_init_features( &self, _their_init_features: &PublicKey ) -> InitFeatures
InitFeatures
which are sent in our Init
message. Read moresource§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> Confirm for ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> Confirm for ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
source§fn transactions_confirmed(
&self,
header: &BlockHeader,
txdata: &TransactionData<'_>,
height: u32
)
fn transactions_confirmed( &self, header: &BlockHeader, txdata: &TransactionData<'_>, height: u32 )
source§fn best_block_updated(&self, header: &BlockHeader, height: u32)
fn best_block_updated(&self, header: &BlockHeader, height: u32)
source§fn get_relevant_txids(&self) -> Vec<(Txid, Option<BlockHash>)>
fn get_relevant_txids(&self) -> Vec<(Txid, Option<BlockHash>)>
source§fn transaction_unconfirmed(&self, txid: &Txid)
fn transaction_unconfirmed(&self, txid: &Txid)
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> EventsProvider for ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> EventsProvider for ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
source§fn process_pending_events<H: Deref>(&self, handler: H)where
H::Target: EventHandler,
fn process_pending_events<H: Deref>(&self, handler: H)where H::Target: EventHandler,
Processes events that must be periodically handled.
An EventHandler
may safely call back to the provider in order to handle an event.
However, it must not call Writeable::write
as doing so would result in a deadlock.
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> Listen for ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> Listen for ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
source§fn filtered_block_connected(
&self,
header: &BlockHeader,
txdata: &TransactionData<'_>,
height: u32
)
fn filtered_block_connected( &self, header: &BlockHeader, txdata: &TransactionData<'_>, height: u32 )
source§fn block_disconnected(&self, header: &BlockHeader, height: u32)
fn block_disconnected(&self, header: &BlockHeader, height: u32)
source§fn block_connected(&self, block: &Block, height: u32)
fn block_connected(&self, block: &Block, height: u32)
source§impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> MessageSendEventsProvider for ChannelManager<M, T, ES, NS, SP, F, R, L>where
M::Target: Watch<<SP::Target as SignerProvider>::Signer>,
T::Target: BroadcasterInterface,
ES::Target: EntropySource,
NS::Target: NodeSigner,
SP::Target: SignerProvider,
F::Target: FeeEstimator,
R::Target: Router,
L::Target: Logger,
impl<M: Deref, T: Deref, ES: Deref, NS: Deref, SP: Deref, F: Deref, R: Deref, L: Deref> MessageSendEventsProvider for ChannelManager<M, T, ES, NS, SP, F, R, L>where M::Target: Watch<<SP::Target as SignerProvider>::Signer>, T::Target: BroadcasterInterface, ES::Target: EntropySource, NS::Target: NodeSigner, SP::Target: SignerProvider, F::Target: FeeEstimator, R::Target: Router, L::Target: Logger,
source§fn get_and_clear_pending_msg_events(&self) -> Vec<MessageSendEvent>
fn get_and_clear_pending_msg_events(&self) -> Vec<MessageSendEvent>
Returns MessageSendEvent
s strictly ordered per-peer, in the order they were generated.
The returned array will contain MessageSendEvent
s for different peers if
MessageSendEvent
s to more than one peer exists, but MessageSendEvent
s to the same peer
is always placed next to each other.
Note that that while MessageSendEvent
s are strictly ordered per-peer, the peer order for
the chunks of MessageSendEvent
s for different peers is random. I.e. if the array contains
MessageSendEvent
s for both node_a
and node_b
, the MessageSendEvent
s for node_a
will randomly be placed first or last in the returned array.
Note that even though BroadcastChannelAnnouncement
and BroadcastChannelUpdate
MessageSendEvent
s are intended to be broadcasted to all peers, they will be pleaced among
the MessageSendEvent
s to the specific peer they were generated under.