f

Move commitment tx fee calculation helpers to `chan_utils`

These don't really belong in `channel` as they're now used in other
parts of the codebase.

Drop `chan_utils` self-import

There's no reason to `use` a module within that module to refer to
that module...

Include an `outbound_payment` flag in `MaybeTimeoutClaimableHTLC`

When the user is fetching their current balances after forwarding a
payment (before it clears), they'll see a
`MaybePreimageClaimableHTLC` and a `MaybeTimeoutClaimableHTLC` but
if they sum up their balance using
`Balance::claimable_amount_satoshis` neither will be included.

Obviously, exactly one of the two balances should be included - one
of the two resolutions should happen in our favor. This causes our
visible balance to fluctuate up and down by the full value of any
HTLCs we're in the middle of forwarding, which is incredibly
confusing to see. If we want to stop the fluctuations, we need to
pick one of the two balances to include. The obvious candidate is
`MaybeTimeoutClaimableHTLC` as it is the lower of the two, and
represents our balance without the fee we'd receive from the
forward.

Sadly, if we always include it, we'll end up also including any
HTLCs which we've sent but which haven't yet been claimed by their
recipient, which is the wrong behavior.

Luckily, we have access to the `Option<HTLCSource>` while walking
HTLCs, which allows us to add an `outbound_payment` flag to
`MaybeTimeoutClaimableHTLC`. This allows us to only include
forwarded payments in `claimable_amount_satoshis`.

Sadly, even with this in place our balance still fluctuates by the
changes in the commitment transaction fees we have to pay during
forwarding, but addressing that is left for later.

Merge pull request #2529 from TheBlueMatt/2023-08-shutdown-remove-early-sign

Don't send init `closing_signed` too early after final HTLC removal

Merge pull request #2726 from shaavan/issue2712

Log the error, when trying to forward the intercepted HTLC, but the channel is not found

Log the error, when trying to forward the intercepted HTLC, but the

channel is not found

Merge pull request #2716 from TheBlueMatt/2023-11-hash-if-eq

`derive(Hash)` for P2P messages

`derive(Hash)` for P2P messages

In other languages (Java and C#, notably), overriding `Eq` without
overriding `Hash` can lead to surprising or broken behavior. Even
in Rust, its usually the case that you actually want both. Here we
add missing `Hash` derivations for P2P messages, to at least
address the first pile of warnings the C# compiler dumps.

Rely on const generic big arrays for `PartialEq` in msgs

Implementation of standard traits on arrays longer than 32 elements
was shipped in rustc 1.47, which is below our MSRV of 1.48 and we
can use to remove some unnecessary manual implementation of
`PartialEq` on `OnionPacket`.

Merge pull request #2544 from optout21/splicing-msgs0

Add Splicing (and Quiescence) wire message definitions

Merge pull request #2732 from arik-so/2023/11/update-musig2-dep

Update MuSig2 dependency for Hash trait derivation.

Merge pull request #2708 from TheBlueMatt/2023-11-less-graph-memory-frag

Reduce common allocations across the codebase

Update MuSig2 dependency for Hash trait derivation.

Merge pull request #2715 from valentinewallace/2023-11-skimmed-fees

Complete underpaying HTLCs support

Merge pull request #2722 from benthecarman/dust-overflow

Fix potential cases where max_dust_htlc_exposure_msat overflows

Don't send init `closing_signed` too early after final HTLC removal

If we remove an HTLC (or fee update), commit, and receive our
counterparty's `revoke_and_ack`, we remove all knowledge of said
HTLC (or fee update). However, the latest local commitment
transaction that we can broadcast still contains the HTLC (or old
fee), thus we are not eligible for initiating the `closing_signed`
negotiation if we're shutting down and are generally expecting a
counterparty `commitment_signed` immediately.

Because we don't have any tracking of these updates in the `Channel`
(only the `ChannelMonitor` is aware of the HTLC being in our latest
local commitment transaction), we'd previously send a
`closing_signed` too early, causing LDK<->LDK channels with an HTLC
pending towards the channel initiator at the time of `shutdown` to
always fail to cooperatively close.

To fix this race, we add an additional unpersisted bool to
`Channel` and use that to gate sending the initial `closing_signed`.

Stop writing signer data as a part of channels

This breaks backwards compatibility with versions of LDK prior to
0.0.113 as they expect to always read signer data.

This also substantially reduces allocations during `ChannelManager`
serialization, as we currently don't pre-allocate the `Vec` that
the signer gets written in to. We could alternatively pre-allocate
that `Vec`, but we've been set up to skip the write entirely for a
while, and 0.0.113 was released nearly a year ago. Users
downgrading to LDK 0.0.112 and before at this point should not be
expected.

Avoid allocating when checking gossip message signatures

When we check gossip message signatures, there's no reason to
serialize out the full gossip message before hashing, and it
generates a lot of allocations during the initial startup when we
fetch the full gossip from peers.

Avoid a `tokio::mpsc::Sender` clone for each P2P send operation

Whenever we go to send bytes to a peer, we need to construct a
waker for tokio to call back into if we need to finish sending
later. That waker needs some reference to the peer's read task to
wake it up, hidden behind a single `*const ()`. To do this, we'd
previously simply stored a `Box<tokio::mpsc::Sender>` in that
pointer, which requires a `clone` for each waker construction. This
leads to substantial malloc traffic.

Instead, here, we replace this box with an `Arc`, leaving a single
`tokio::mpsc::Sender` floating around and simply change the
refcounts whenever we construct a new waker, which we can do
without allocations.

Avoid re-allocating to encrypt gossip messages when forwarding

When we forward gossip messages, we store them in a separate buffer
before we encrypt them (and commit to the order in which they'll
appear on the wire). Rather than storing that buffer encoded with
no headroom, requiring re-allocating to add the message length and
two MAC blocks, we here add the headroom prior to pushing it into
the gossip buffer, avoiding an allocation.

Fix potential cases where max_dust_htlc_exposure_msat overflows

Link to LSP spec in accept_underpaying_htlcs config

Include counterparty skimmed fees in PaymentClaimed event.

Merge pull request #2702 from G8XSU/libFuzzer

Update fuzzing instructions for libFuzzer/cargo-fuzz

Use `VecDeque`, rather than `LinkedList` in peer message buffering

When buffering outbound messages for peers, `LinkedList` adds
rather substantial allocation overhead, which we avoid here by
swapping for a `VecDeque`.

Avoid unnecessarily alloc'ing a new buffer when decrypting messages

When decrypting P2P messages, we already have a read buffer that we
read the message into. There's no reason to allocate a new `Vec` to
store the decrypted message when we can just overwrite the read
buffer and call it a day.

Add an option to in-place decrypt with `ChaCha20Poly1305`

In the next commit we'll use this to avoid an allocation when
deserializing messages from the wire.

Merge pull request #2714 from TheBlueMatt/2023-11-one-less-alloc

Avoid an unnecessary allocation in `TaggedHash`

Add Splicing (and Quiescence) wire message definitions

Avoid an unnecessary allocation in `TaggedHash`

A well-formed tag is always a constant, so allocating to store it
is unnecessary when we can just make the tag a `&'static str`.

Merge pull request #2687 from orbitalturtle/signature-data-enum

Expose more granular data in TaggedHash struct

Merge pull request #2677 from Evanfeenstra/public-onion-utils

public create_payment_onion in onion_utils

Pre-allocate the full `Vec` prior to serializing as a `Vec<u8>`

We end up generating a substantial amount of allocations just
doubling `Vec`s when serializing to them, and our
`serialized_length` method is generally rather effecient, so we
just rely on it and allocate correctly up front.

expose more granular data in TaggedHash struct

Expose tag and merkle root fields in the TaggedHash struct.

refactor to remove message_digest

We change the Bolt12Invoice struct to carry a tagged hash. Because
message_digest is then only used in one place, we can inline it in
the TaggedHash constructor.

Update fuzzing instructions for libFuzzer/cargo-fuzz

export create_onion_message and peel_onion_message from ln::onion_message

public create_payment_onion in onion_utils

Merge pull request #2699 from mhrheaume/mhr/temporary_channel_id

Added `temporary_channel_id` to `create_channel`.

Avoid unnecessarily overriding `serialized_length`

...as LLVM will handle it just fine for us, in most cases.

Pre-allocate send buffer when forwarding gossip

When forwarding gossip, rather than relying on Vec doubling,
pre-allocate the message encoding buffer.

Prefer `Writeable.encode()` over `VecWriter` use

It does the same thing and its much simpler.

Reduce on-startup heap frag due to network graph map/vec doubling

When we're reading a `NetworkGraph`, we know how many
nodes/channels we are reading, there's no reason not to
pre-allocate the `IndexedMap`'s inner `HashMap` and `Vec`, which we
do here.

This seems to reduce on-startup heap fragmentation with glibc by
something like 100MiB.

Added `temporary_channel_id` to `create_channel`.

By default, LDK will generate the initial temporary channel ID for you.
However, in certain cases, it's desirable to have a temporary channel ID
specified by the caller in case of any pre-negotiation that needs to
happen between peers prior to the channel open message. For example, LND
has a `FundingShim` API that allows for advanced funding flows based on
the temporary channel ID of the channel.

This patch adds support for optionally specifying the temporary channel
ID of the channel through the `create_channel` API.

Merge pull request #2558 from waterson/pr-2554

Handle retrying sign_counterparty_commitment failures

Merge pull request #2641 from alexanderwiederin/2585-preflight-test-coverage

#2585 Preflight Test Coverage

Add basic async signer tests

Adds a `get_signer` method to the context so that a test can get ahold of the
channel signer. Adds a `set_available` method on the `TestChannelSigner` to
allow a test to enable and disable the signer: when disabled some of the
signer's methods will return `Err` which will typically activate the error
handling case. Adds a `set_channel_signer_available` function on the test
`Node` class to make it easy to enable and disable a specific signer.

Adds a new `async_signer_tests` module:

* Check for asynchronous handling of `funding_created` and `funding_signed`.
* Check that we correctly resume processing after awaiting an asynchronous
  signature for a `commitment_signed` event.
* Verify correct handling during peer disconnect.
* Verify correct handling for inbound zero-conf.

Handle retrying sign_counterparty_commitment inb funding failures

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

This commit adds retrying of inbound funding_created signing
failures, regenerating the `FundingSigned` message, attempting to
re-sign, and sending it to our peers if we succeed.

Handle retrying sign_counterparty_commitment outb funding failures

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

This commit adds retrying of outbound funding_created signing
failures, regenerating the `FundingCreated` message, attempting to
re-sign, and sending it to our peers if we succeed.

Handle retrying sign_counterparty_commitment failures

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

This commit adds initial retrying of failures, specifically
regenerating commitment updates, attempting to re-sign the
`CommitmentSigned` message, and sending it to our peers if we
succed.

Handle sign_counterparty_commitment failing during inb funding

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

Here we add initial handling of sign_counterparty_commitment
failing during inbound channel funding, setting a flag in
`ChannelContext` which indicates we should retry sending the
`funding_signed` later. We don't yet add any ability to do that
retry.

Handle sign_counterparty_commitment failing during outb funding

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending which required the signature later,
rather than force-closing the channel (which probably won't even
work if the signer is missing).

Here we add initial handling of sign_counterparty_commitment
failing during outbound channel funding, setting a new flag in
`ChannelContext` which indicates we should retry sending the
`funding_created` later. We don't yet add any ability to do that
retry.

Handling for sign_counterparty_commitment failing during normal op

If sign_counterparty_commitment fails (i.e. because the signer is
temporarily disconnected), this really indicates that we should
retry the message sending later, rather than force-closing the
channel (which probably won't even work if the signer is missing).

Here we add initial handling of sign_counterparty_commitment
failing during normal channel operation, setting a new flag in
`ChannelContext` which indicates we should retry sending the
commitment update later. We don't yet add any ability to do that
retry.

Merge pull request #2682 from jkczyz/2023-09-bolt12-test-vectors

BOLT 12 Offer test vectors

add preflight probes test coverage

Merge pull request #2686 from jkczyz/2023-10-onion-message-fuzz

Re-add one-hop onion message fuzzing test

Merge pull request #2668 from TheBlueMatt/2023-10-fix-doc

Update docs on `MonitorEvent::HolderForceClosed`

Merge pull request #2693 from Evanfeenstra/next-hop-pubkey-secp-mode

next_hop_pubkey secp Verification only

Merge pull request #2669 from benthecarman/trace-sync-progress

Remove channel monitor sync in progress log

Merge pull request #2689 from benthecarman/no-std-offer-expire

Add `is_expired_no_std` to Offer

Merge pull request #2613 from wvanlint/batch_funding_fix_up

Refactor ShutdownResult type and construction

next_hop_pubkey secp Verification only

Add is_expired_no_std to Offer & Refund

This was available for OfferContents but not an Offer so dependent
projects could not access it.

Re-add one-hop onion message fuzzing test

Revert fuzz test removal in 6dc42235baaa22320ad78d3e05fab31edad99328.
The test originally checked that OnionMessenger would fail for one-hop
blinded paths. The commit added support for such paths, but changing the
checks was not sufficient since the node was not connected to the
introduction node of the reply path. This is required in order to work
with the trivial TestMessageRouter. Fix this by explicitly connecting
the nodes.

Wrap long onion_message fuzz strings

Some editors like vim slow to a crawl when scrolling over long strings
when syntax highlighting is turned on. Limit the length in fuzz strings
to avoid this.

BOLT 12 test vectors for offer parsing

One discrepancy from the spec still needs to be resolved:

https://github.com/lightning/bolts/pull/798/files#r1334851959

Separate and describe BOLT 12 test vectors

Move bech32 parsing tests to the parse module

Additional BOLT 12 tests specific to Offer were added, which will live
in the offer module. Thus, it makes sense to move the bech32 tests to
the parse module.

Merge pull request #2678 from TheBlueMatt/2023-10-0.0.118

Cut 0.0.118

Bump crate versions to lightning 0.0.118, invoice 0.26

0.0.118 release notes

Merge pull request #2679 from TheBlueMatt/2023-10-116-bindings-1

Small bindings tweaks for 0.0.118

Fix CI on rustc 1.50 and below

rustc doesn't allow `--features` with `-p`, so we simply skip the
steps that rely on it.

Use a tuple, not a struct, for `PendingOnionMessage` in bindings

Bindings aren't currently able to handle a struct with a generic
which is actually exposed - we map all structs concretely to a
single type, whereas having fluctuating types on a struct requires
mapping the inner field to a trait first.

Since this isn't super practical, we make `PendingOnionMessage` a
tuple in bindings, rather than a struct.

Merge pull request #2676 from TheBlueMatt/2023-10-various-followups

Various Followups to 2039 and 2674

Add relevant no-export tags to functions returning builders

Because we can't map move semantics in most languages, we also
can't map our current builders. Thus, we have to mark them
no-export.

Drop an unnecessary no-export on ParsedOnionMessageContents

Do not compile the `Simple*` type aliases in `c_bindings` at all

Because the bindings changes now require further changes to our
type definitions, avoiding building the `Simple*` type aliases
entirely makes the patchset there simpler.

Fix (and test) the `c_bindings` build flag

Rather than only building with the `c_bindings` flag in certain
crates, we go ahead and test all crates with the flag in CI here.

Remove some additional excess words in `ConfirmationTarget` docs

Remove a redundant sentence in `ConfirmationTarget` docs

... and correct direction which causes force-closure in another
sentence.

Drop unused `use` import.

Avoid a redundant allocation in `InvoiceError` handling in one case

... by passing an owned `String`, rather than taking an `&str` and
`to_owned()`ing it.

Use `Default::default()` for scoring params in tests

In 26c1639ab69d6780c97a118f09e42cb42304088a we switched to using
`Default::default()` to initialize `()` for scoring parameters in
tests. A number of `()`s slipped back in recently, which we replace
here.

Merge pull request #2667 from wpaulino/random-htlc-holder-sigs-non-anchors

Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs

Merge pull request #2674 from wpaulino/consider-anchor-outputs-value-balances

Consider anchor outputs value throughout balance checks and computations

Move HTLCDescriptor to sign module

Now that `HTLCDescriptor` is no longer specific to anchors, it doesn't
make sense for it to live in the `bump_transaction` module anymore.

Don't sign holder HTLCs along with holder commitments

`sign_holder_commitment_and_htlcs` never really made sense. Unlike
`sign_counterparty_commitment`, the signatures for holder HTLC
transactions may be required much later than the commitment
transaction's. While it was nice for us to only reach the signer once to
obtain all holder signatures, it's not really ideal anymore as we want
our signatures to be random and not reused.

We no longer return all holder HTLC signatures and instead defer to
obtaining them via `EcdsaChannelSigner::sign_holder_htlc_transaction`.

Remove caching of holder HTLC signatures

Since we want our holder HTLC signatures to be randomly generated and
not reused, our existing caches are useless now, so we opt to remove
them.

Use sign_holder_htlc_transaction to sign non-anchors holder HTLCs

We want to ensure we use fresh random signatures to prevent certain
classes of transaction replacement attacks at the bitcoin P2P layer.
This was already covered for commitment transactions and zero fee holder
HTLC transactions, but was missing for holder HTLC transactions on
non-anchors channels.

We can easily do this by reusing the existing
`EcdsaChannelSigner::sign_holder_htlc_transaction` method and
circumventing the existing `holder_htlc_sigs/prev_holder_htlc_sigs`
caches, which will be removed in a later commit anyway.

Apply a default max fee rather than none when paying for BOLT12

If the user declines to specify a `max_total_routing_fee_msat` in
the new BOLT12 payment methods, rather than defaulting to no limit
on the fee we pay at all, we should default to our "usual default",
ie the one calculated in
`RouteParameters::from_payment_params_and_value`.

We do this here, as well as documenting the behavior on the payment
methods.

Only account for fee spike buffer multiple on non-anchor channels

Anchor outputs channels are no longer susceptible to fee spikes as they
now mostly target the dynamic minimum mempool fee and can contribute the
remainder of fees when closing.

Consider anchor outputs value on channel open

We should make sure the funding amount of a channel can cover all its
associated costs, including the value of anchor outputs, to make sure
that it is actually usable once "opened".

Consider anchor outputs value on inbound HTLCs

This could lead us to accept HTLCs that would put the sender below
their reserve, which must never happen.

Consider anchor outputs value in get_available_balances

This could lead us to sending/forwarding HTLCs that would put us below
our reserve, forcing our counterparty to close the channel on us due to
an invalid update.

Run chanmon_consistency_test with anchor outputs channels

Provide missing derivation parameters to OnchainTxHandler

`OnchainTxHandler` will need to construct `HTLCDescriptor`s for holder
HTLCs, but it did not have access to all of the derivation parameters
that need to be provided.

Support signing non-anchors HTLCs with HTLCDescriptor

We plan to use `EcdsaChannelSigner::sign_holder_htlc_transaction` to
also sign holder HTLC transactions on non-anchor outputs channels.
`HTLCDescriptor` was only used in an anchor outputs context, so a few
things needed changing, mostly to handle the different scripts and
feerate.

Merge pull request #2660 from benthecarman/flexible-fee-rate

More flexible fee rate estimates