Matt Corallo [Wed, 19 Jul 2023 20:04:24 +0000 (20:04 +0000)]
Mark the `Duration` serialization implementation no-bindings-export
The bindings are being updated to consider all traits even if the
trait itself is no-export, which causes issues generating code
around the `Duration` impl here.
Matt Corallo [Wed, 19 Jul 2023 20:02:10 +0000 (20:02 +0000)]
No-export un-exportable types in BOLT12 module
We missed one method that now cannot be bindings exported - the
`payment_paths` method, as it returns a slice of objects, which
cannot be supported in bindings.
Matt Corallo [Wed, 19 Jul 2023 19:37:21 +0000 (19:37 +0000)]
Tweak PSBT signing for bindings compatibility
In bindings we can't practically pass a mutable PSBT, and instead
need to pass an owned transaction and have the sign method return a
signed copy. We do this here for all build modes as its not a
material API change for Rust users.
Matt Corallo [Tue, 18 Jul 2023 19:52:26 +0000 (19:52 +0000)]
Drop `c_bindings` implementation of scoring on `Mutex`/`RefCell`
This code was always effectively dead - we have a special
`MultiThreadedLockableScore` type which wraps a `Mutex` for
bindings users, so there's no need to implement any
bindings-specific scoring logic for them.
Matt Corallo [Tue, 18 Jul 2023 19:41:07 +0000 (19:41 +0000)]
Pass `InFlightHltcs` to the scorer by ownership rather than ref
Given we build `InFlightHtlcs` per route-fetch call, there's no
reason to pass them out by reference rather than simply giving the
user the full object. This also allows them to tweak the in-flight
set before fetching a route.
Matt Corallo [Tue, 18 Jul 2023 19:34:00 +0000 (19:34 +0000)]
Pass must-spend inputs to users by ownership
We already hold them in a vec, so there's no cost to passing them
by ownership vs making it a slice. Further, this helps bindings as
we can't represent slices to non-pointers in a sensible way.
Matt Corallo [Tue, 18 Jul 2023 19:13:19 +0000 (19:13 +0000)]
Tweak transaction bumping `sign_tx` types for bindings
In bindings we can't practically pass a mutable transaction, and
instead need to pass an owned transaction and have the sign method
return a signed copy. We do this here for all build modes as the
API is roughly equivalent also to Rust users.
Duncan Dean [Fri, 14 Jul 2023 14:59:29 +0000 (16:59 +0200)]
Close and remove unfunded inbound/outbound channels that are older than an hour
We introduce a `UnfundedChannelContext` which contains a counter for the
current age of an unfunded channel in timer ticks. This age is incremented
for every `ChannelManager::timer_tick_ocurred` and the unfunded channel
is removed if it exceeds `UNFUNDED_CHANNEL_AGE_LIMIT_TICKS`.
The value will not be persisted as unfunded channels themselves are not
persisted.
Duncan Dean [Mon, 26 Jun 2023 14:06:50 +0000 (10:06 -0400)]
Add missing unfunded channel maps checks in `ChannelManager`
One of a series of follow-up commits to address some issues found
in PR 2077, where we split channels up into different maps and structs
depending on phase in their life.
Duncan Dean [Mon, 17 Jul 2023 13:52:44 +0000 (15:52 +0200)]
Refer to channels busy with funding tx negotiation as "unfunded"
We had some inconsistencies so far in referring to channels such as
`OutboundV1Channel` and `InboundV1Channel` as pending and unfunded.
From here we refer to these kinds of channels only as "unfunded".
This is a slight conflation with the term "unfunded" in the contexts
of denial of service mitigation. There, "unfunded" actually refers to
non-0conf, inbound channels that have not had their funding transaction
confirmed. This might warrant changing that usage to "unconfirmed inbound".
Matt Corallo [Tue, 18 Jul 2023 19:04:56 +0000 (19:04 +0000)]
Tweak generics on `derive_channel_signer` to be bindings-compatible
The C bindings generation currently has issues looking through a
generic associated type. While this should be fixed in the bindings
generator, its easy to fix here for now and we can revisit it
later.
Matt Corallo [Mon, 17 Jul 2023 21:01:02 +0000 (21:01 +0000)]
Drop `tokio/macros` dependency in `lightning-net-tokio`, fix MSRV
The `tokio` `macros` feature depends on `proc-macro2`, which
recently broke its MSRV in a patch version. Such crates aren't
reasonable for us to have as dependencies, so instead we replace
the one trivial use we have of `tokio::select!()` with our own
manual future.
The `RefCell` was necessary in a previous iteration of the code in which
the iterator was not `Clone` so we needed interior mutability in order
to consume the iterator. Now that it is `Clone`, we can drop it, as
we're no longer mutating the original iterator.
Use min mempool feerate for outbound updates on anchor channels
As done with inbound feerate updates, we can afford to commit less in
fees, as long as we still may the minimum mempool feerate. This enables
users to spend a bit more of their balance, as less funds are being
committed to transaction fees.
Relax constraints for inbound feerate updates on anchor channels
Channels supporting anchors outputs no longer require their feerate
updates to target a prompt confirmation since commitment transactions
can be bumped when broadcasting. Commitment transactions must now at
least meet the minimum mempool feerate, until package relay is deployed,
such that they can propagate across node mempools in the network by
themselves.
The existing higher bound no longer applies to channels supporting
anchor outputs since their HTLC transactions don't have any fees
committed, which directly impact the available balance users can send.
Add new ConfirmationTarget variant for min mempool feerates
Now that we support channels with anchor outputs, we add a new
ConfirmationTarget variant that, for now, will only apply to such
channels. This new variant should target estimating the minimum feerate
required to be accepted into most node mempools across the network.
Consider existing commitment transaction feerate when bumping
With anchors, we've yet to change the frequency or aggressiveness of
feerate updates, so it's likely that commitment transactions have a
good enough feerate to confirm on its own. In any case, when producing a
child anchor transaction, we should already take into account the fees
paid by the commitment transaction itself, allowing the user to save
some satoshis. Unfortunately, in its current form, this will still
result in overpaying by a small margin at the expense of making the coin
selection API more complex.
Avoid yielding ChannelClose bump events with sufficient feerate
There's no need to yield such an event when the commitment transaction
already meets the target feerate on its own, so we can simply broadcast
it without an anchor child transaction. This may be a common occurrence
until we are less aggressive about feerate updates.
Matt Corallo [Wed, 5 Jul 2023 17:06:19 +0000 (17:06 +0000)]
Add comment describing when a completion action can be discarded
In an older PR a reviewer had asked why the discarding of a channel
being blocked on another monitor update is okay if the blocked
channel has since closed. At the time, this was not actually okay -
the monitor updates in the channel weren't moved to the
`ChannelManager` on close so the whole pipeline was busted, but
with the changes in 4041f0899f86eaf6a0a4576a91918fa54026ac46 the
handling of channel closes with pending monitor updates is now
correct, and so is the existing code block.
Matt Corallo [Wed, 5 Jul 2023 02:15:42 +0000 (02:15 +0000)]
Run monitor update completion actions for pre-startup completion
If a `ChannelMonitorUpdate` completes being persisted, but the
`ChannelManager` isn't informed thereof (or isn't persisted) before
shutdown, on startup we may still have it listed as in-flight. When
we compare the available `ChannelMonitor` with the in-flight set,
we'll notice it completed and remove it, however this may leave
some post-update actions dangling which need to complete.
Here we handle this with a new `BackgroundEvent` indicating we need
to handle any post-update action(s) for a given channel.
Matt Corallo [Fri, 7 Jul 2023 21:05:29 +0000 (21:05 +0000)]
Drop `vec_type` TLV handling entirely
Historically, we used `vec_type` for all TLV Vec reads/writes, but
it is asymmetric and thus somewhat confusing - on the write side it
always writes a TLV entry, even if there are zero elements. On the
read side, it happily accepts a missing TLV, providing a
zero-length vector.
Matt Corallo [Fri, 7 Jul 2023 19:57:23 +0000 (19:57 +0000)]
Convert `channelmonitor` `vec_type` TLV writes to required/optional
* `HolderSignedTx::htlc_outputs` has always been written since it
was converted to TLVs in 86641ea68062388a01c99c6ed131f56477c8e4.
* `ChanelMonitorUpdateStep::*::htlc_outputs` have been written
since the enum was converted to TLVs in 86641ea68062388a01c99c6.
Matt Corallo [Tue, 4 Jul 2023 15:13:32 +0000 (15:13 +0000)]
Handle monitor completion actions for closed channels
If a channel has been closed, there may still be some
`ChannelMonitorUpdate`(s) which are pending completion. These
in-flight updates may also be blocking another channel from letting
an update fly, e.g. for forwarded payments where the payment
preimage will be removed from the downstream channel after the
upstream channel has closed.
Luckily all the infrastructure to handle this case is already in
place - we just need to process the
`monitor_update_blocked_actions` for closed channels.
Matt Corallo [Tue, 20 Jun 2023 22:52:27 +0000 (22:52 +0000)]
Don't drop `ChannelMonitor` `Event`s until they're processed
We currently assume the owner of `ChannelMonitor`s won't persist
the `ChannelMonitor` while `Event`s are being processed. This is
fine, except (a) its generally hard to do so and (b) the
`ChainMonitor` doesn't even do this.
Thus, in rare cases, a user could begin processing events which
are, generated by connecting a transaction or a new best-block,
take some time to do so, and while doing so process a further chain
event, causing persistece. This could lose the event being
processed alltogether, which could lose the user funds.
This should be very rare, but may have been made slightly more
reachable with (a) the async event processing making it more
common to do networking in event handling, (b) the new future
generation in the `ChainMonitor`, which now wakes the
`background-processor` directly when chain actions happen on the
`ChainMonitor`.
Handle new event processing logic when enqueuing forward event
This was a regression resulting from f2453b7 since we now process events
in a loop until there aren't any left. Processing events is done in
batches and they are not removed until we're done processing each batch.
Since handling a `PendingHTLCsForwardable` event will call back into the
`ChannelManager`, we'll still see the original forwarding event not
removed. Phantom payments will need an additional forwarding event
before being claimed to make them look real by taking more time.
benthecarman [Thu, 18 May 2023 20:43:56 +0000 (15:43 -0500)]
Add helper functions to verify node and channel annoucements
Right now the only real way to verify the node and channel
announcements is to call `update_node_from_announcement`/
`update_channel_from_announcement`. If you want to do some
processing before you add to your network graph then you need to
manually verify the signature. This adds some nice helper functions
to make it easier.
I tried to do the same for channel update but it did not seem as
easy so figured that is fine to punt on since I don't see many
people doing manual things with channel updates.
Matt Corallo [Thu, 4 May 2023 21:51:18 +0000 (21:51 +0000)]
Re-claim forwarded HTLCs on startup
Because `ChannelMonitorUpdate`s can complete asynchronously and
out-of-order now, a `commitment_signed` `ChannelMonitorUpdate` from
a downstream channel could complete prior to the preimage
`ChannelMonitorUpdate` on the upstream channel. In that case, we may
not get a `update_fulfill_htlc` replay on startup. Thus, we have to
ensure any payment preimages contained in that downstream update are
re-claimed on startup.
Here we do this during the existing walk of the `ChannelMonitor`
preimages for closed channels.
Matt Corallo [Fri, 7 Jul 2023 19:27:15 +0000 (19:27 +0000)]
Convert routing `vec_type `TLV writes to other TLV types
* `BlindedTail::hops` has always been written since it was
introduced in 64c26c8a793f35c55076a2188912e92106900bab.
* `PaymentParameters::clear_hints` has always been written since
it was introduced as `Payee::route_hitns` in 46b68c517dba57bde5.
Matt Corallo [Fri, 7 Jul 2023 20:55:12 +0000 (20:55 +0000)]
Migrate `chan_utils` `vec_type` TLVs to required/optional
* `CommitmentTransaction::htlcs` has always been written since the
struct was converted to TLVs in 66784e32fe454e9a5b2080b85fc4d881.
* `HolderCommitmentTransaction::counterparty_htlc_sigs` have always
been written since the struct was converted to TLVs in c8bc1b6d3de45aeddc755d0875b3dce8d86f79c1.
Matt Corallo [Fri, 7 Jul 2023 18:44:24 +0000 (18:44 +0000)]
Convert some `vec_type` TLVs to `required_vec`
This converts some required TLVs to `required_vec` which are, in
fact, required (and have been written forever).
* `HTLCFailReason` hasn't changed since many structs were converted
to TLVs in 66784e32fe454e9a5b2080b85fc4d8816ac5e436.
* `NodeInfo::channels` has been written since `NetworkGraph`
structs were converted to TLVs in 321b19c4d96a49b39b5583d0f12fea.
* Several test-only TLV writes were converted.
Matt Corallo [Fri, 7 Jul 2023 18:38:06 +0000 (18:38 +0000)]
Add a `required_vec` TLV deserialization type
Historically, we used `vec_type` for all TLV Vec reads/writes, but
it is asymmetric and thus somewhat confusing - on the write side it
always writes a TLV entry, even if there are zero elements. On the
read side, it happily accepts a missing TLV, providing a
zero-length vector.
In 85b573ddad70f3c5ee36e0992d587842af507a8d a new `optional_vec`
TLV format was added which was symmetric, but only supports
optional vecs. This adds the corresponding required form, always
writing a TLV and ensuring it is present.
Use multiplier in dust exposure threshold calculation
This commit makes use of the added enum to calculate the dust
exposure threshold based on the current fee rate. This also updates
tests to ensure it works as intended.
Alec Chen [Mon, 19 Jun 2023 02:53:43 +0000 (21:53 -0500)]
Add max dust exposure multiplier config knob
With fee rates rising dramatically in mid-April 2023, thresholds for
what is considered dust have risen, often exceeding our previous dust
exposure threshold of 5k sats. This causes all payments and HTLC
forwards between 5k sats and new dust thresholds to fail.
This commit changes our max dust exposure config knob from a fixed
upper limit to a `MaxDustHTLCExposure` enum with an additional variant
to allow setting our max dust exposure to a multiplier on the current
high priority feerate.
To remain backwards compatible we'll always write the fixed limit if
it's set, or its default value in its currently reserved TLV.
We also now write an odd TLV for the new enum, so that previous
versions can safely ignore it upon downgrading, while allowing us to
make use of the new type when it's written.
Matt Corallo [Fri, 7 Jul 2023 18:28:25 +0000 (18:28 +0000)]
Fix backwards compat for `blocked_monitor_updates`
In 1ce2beb77455a674888f3e3589723195eaa7b13c,
`Channel::blocked_monitor_updates` was moved to an even TLV to
ensure downgrades with vec entries are forbidden. However, the
serialized type remained `vec_type`, which is always written.