Once we support zero-fee commitment transactions, we will no longer
have a constant number of maximum HTLCs in-flight per channel but
rather it will depend on the channel type.
Here we prepare for this by removing the `MAX_HTLCS` constant and
replacing it with a function.
As we move towards zero-fee commitment transactions, we need to
differentiate between the now-two-types of "anchor channels".
We do so here by renaming a number of methods which refer to
anchors as "keyed anchors" as the zero-fee commitment transaction
anchors do not have a public key associated with them.
We also drop `TaprootChannelSigner::sign_holder_anchor_input` as
we are unlikely to support keyed anchors for taproot channels.
For some reason when attempting to raise floats to powers in
scoring we'd converted our `f64`s to `f32`s, called `libm::powf`
(on no-std targets), then converted the result back to an `f64`.
`libm::pow`, however, exists and raises `f64`s to a power natively.
Here we correct this, using the proper `f64`-native `pow`.
While I doubt its related, I went to look if we have any conversion
in LDK itself in response to
https://github.com/lightningdevkit/ldk-node/issues/483 (where
Android binaries failed to load due to a missing `__extenddftf2`.
This commits prepares the persistence layer for the addition of
attribution data. Changes:
- Expand InboundHTLCRemovalReason serialization instead of using the
macro. When attribution data is added, it can't just be serialized
along with the existing fields because it would break backwards
compatibility. Instead the new field needs to go into the tlv block.
- Stop using OnionErrorPacket in the UpdateFailHTLC message. When
attribution data is added to OnionErrorPacket, it would not be
serialized for the wire properly because also here the new field needs
to go in the tlv extension of the message.
- Prepare HTLCFailReasonRepr serialization for that addition of
attribution data.
Co-authored-by: Matt Corallo <git@bluematt.me>
`LatestCounterpartyCommitmentTXInfo` provides `ChannelMonitor` with the
data it needs to build counterparty commitment transactions.
`ChannelMonitor` then rebuilds commitment transactions from these pieces
of data when requested.
This commit adds a new variant to `ChannelMonitorUpdateStep` called
`LatestCounterpartyCommitmentTX`, which will provide fully built
commitment transactions to `ChannelMonitor`. When `ChannelMonitor` is
asked for counterparty commitment transactions, it will not rebuild
them, but just clone them.
As a result, this new variant eliminates any calls to the upcoming
`TxBuilder` trait in `ChannelMonitor`, which avoids adding a generic
parameter on `ChannelMonitor`. This commit also stomps any bugs that
might come from passing around disparate pieces of data to re-build
commitment transactions from scratch.
We also add a `htlc_outputs` field to the variant to include the dust
HTLCs, as well as all the HTLC sources. This means that this new variant
will store non-dust HTLCs both in the `htlc_outputs` field, and in the
`commitment_tx` field. This is ok for now as the number of HTLCs
per commitment nowadays is very low.
We add code to handle this new variant, but refrain from
immediately setting it. This will allow us to atomically switch from
`LatestCounterpartyCommitmentTXInfo` to `LatestCounterpartyCommitmentTX`
in the future while still allowing downgrades.
These aren't really used anywhere and were only live very briefly,
so there's not really any point in informing our users that we
don't support them. If anything, it will lead to confusion as the
zero-HTLC-fee channel type is generally referred to simply as
"anchor channels".
We've ad-hoc exposed feature-clearing methods for various feature
flags over the years, but there's not a lot of reason to not just
do it for all the flags, so we go ahead and do that here.
We have a handful of methods to clear features from `*Features`
objects, but have ended up with two different API semantics for
them. In the next commit we'll make them all consistent, opting
against the builder pattern as it turns out all of these lines
utilizing it are too long for rustfmt to be happy, so best to clean
them up now so that rustfmt doesn't make a mockery of our code
later.
Handle the initial splice negotiation, without continuing
to transaction negotiation:
- `splice_channel()` for initiating splicing
- handling of `splice_init` and `splice_ack` messages, with checks
- `splice_ack` always fails (use case still imcomplete)
- A test to go through the use case (`test_v1_splice_in`)
The `counterparty_node_id` in `ChannelMonitorUpdate`s was only tracked
to guarantee we could backfill the `ChannelMonitor`'s field once the
update is applied. Now that we require the field to already be set at
the monitor level, we can remove it from the updates without backwards
compatibility concerns as it was written as an odd TLV.
Now that we require `ChannelMonitor`s to track the channel's
counterparty node ID, we can remove the `outpoint_to_peer` map that was
used throughout `MonitorEvent` handling. This is a big win for a
post-splicing future, as we'll no longer have to bother updating this
map when a splice is proposed.
Some existing tests providing coverage have been removed as a result.
New `ChannelMonitor`s created starting from v0.0.110 will already have
this field set, and those created before then will have it set if a
`ChannelMonitorUpdate` created in v0.0.116 or later has been applied.
It would be extremely rare for a user to not fall under either of these
conditions: they opened a channel almost 3 years ago, and haven't had
any activity on it in the last 2 years. Nonetheless, a panic has been
added on `ChannelMonitor` deserialization to ensure users can move
forward by first running a v0.1.* release and sending/routing a payment
or closing the channel before upgrading to v0.2.0.
Increase coverage and prepare for attributable failures which are going
to extend the update_fail_htlc message with an additional field that
needs to be persisted as well.
When parsing inbound HTLCs, we need to provide supplemental information
about potential outgoing hops, which hitherto always required the next
SCID. However, Trampoline uproots the approach because the sender did
not specify the SCID; rather, they rely on us to do the intermediate
routing. Thus we now need to distinguish between SCID-based and node-
ID-based outgoing routing.
When encrypting errors, we currently have the ability to use two shared
secrets for Phantom Node payments.
Trampoline also requires the re-encryption of encrypted errors, first
using the Trampoline shared secret, and then using the outer one.
Given these two cryptographically equivalent use cases, we're renaming
the phantom_shared_secret parameter to secondary_shared_secret, and
explaining the now two contexts in which it will be applicable.
We will be using the same logic for decoding onion payloads for outer
and for Trampoline onions. To accommodate the Trampoline payloads, we
parse a next node ID rather than an SCID.
For pending HTLC info processing, we will later need to access both the
outer and the Trampoline payloads. Thanks to the refactor eliminating
invalid Hop states, this is now possible by accessing the Hop struct,
which will carry both outer and Trampoline payload data when applicable.
Given that blinded Trampoline hops cannot use blinded intermediate hops
between each other, the `current_path_key` used for decrypting the
blinded Trampoline onion cannot be included in the update_add_htlc
message due to the potential presence of intermediate hops.
That means that when we're not the payment initiator, but a Trampoline
hop forwarding a payment along a blinded path, we must include the
blinding point inside the outer onion, which this commit will allow us
to do.
Now that validate_commitment_signed encapsulates all funding-specific
checks, move the holder_commitment_point advancement immediately
following the call to it. While there should be any early returns at
that point, it's good to have move it earlier in case of future changes.
Now that commitment_signed is split into check and accept methods, move
the check portion from FundedChannel to ChannelContext. This allows
calling it with a different FundingScope when there are pending splices
and RBF attempts.
When handling commitment_signed messages, a number of checks are
performed before a ChannelMonitorUpdate is created and returned. Once
splicing is added, these checks need to be performed on the primary
FundingScope and any pending scopes that resulted from splicing or RBF.
This commit splits the handling into a check and accept methods, taking
&self and &mut self, respectively. This ensures that the ChannelContext
is not modified between checks. Once all funding scopes have been
checked successfully, the accept portion of the code can then execute.
