Matt Corallo [Sat, 30 Sep 2023 17:35:21 +0000 (17:35 +0000)]
Implement `Readable`/`Writeable` for `RwLock` wrappers
We now support separate R/W locks in `LockableScore`, which allow
us to do routefinding in parallel, however in order to support
`WriteableScore` for such users we need to implement `Writeable`
for `RwLock` wrappers around `Writeable` types, which we do here.
Persist full monitor if there is an error while applying monitor_update
Motivation: When there is an error while applying monitor_update to a
channel_monitor, we don't want to persist a 'monitor_update' which
results in a failure to apply later while reading 'channel_monitor' with
updates from storage. Instead, we should persist the entire 'channel_monitor'
here.
We were incorrectly marking updates as chain_sync
or not in test_utils based on whether monitor_update
is None or not. Instead, use UpdateOrigin to determine it.
Matt Corallo [Sun, 24 Sep 2023 02:32:08 +0000 (02:32 +0000)]
Fix matching of second-stage HTLC claim in get_htlc_balance
We incorrectly assumed that the descriptor's output index from
second-stage HTLC transaction would always match the HTLC's output index
in the commitment transaction. This doesn't make any sense though, we
need to make sure we map the descriptor to it's corresponding HTLC in
the commitment. Instead, we check that the transaction from which the
descriptor originated from spends the HTLC in question.
Note that pre-anchors, second-stage HTLC transactions are always 1
input-1 output, so previously we would only match if the HTLC was the
first output in the commitment transaction. Post-anchors, they are
malleable, so we can aggregate multiple HTLC claims into a single
transaction making this even more likely to happen. Unfortunately, we
lacked proper coverage in this area so the bug went unnoticed. To
address this, we aim to extend our existing coverage of
`get_claimable_balances` to anchor outputs channels in the following
commits.
Support signing to_remote anchors variant for StaticPaymentOutput
`to_remote` outputs on commitment transactions with anchor outputs have
an additional `1 CSV` constraint on its spending condition,
transitioning away from the previous P2WPKH script to a P2WSH.
Since our `ChannelMonitor` was never updated to track the proper
`to_remote` script on anchor outputs channels, we also missed updating
our signer to handle the new script changes.
Use correct to_remote script in counterparty commitments
While our commitment transactions did use the correct `to_remote`
script, the `ChannelMonitor`'s was not as it is tracked separately. This
would lead to users never receiving an `Event::SpendableOutputs` with a
`StaticPaymentOutput` descriptor to claim the funds.
Luckily, any users affected which had channel closures confirmed by a
counterparty commitment just need to replay the closing transaction to
receive the event.
Avoid early return upon confirmation of channel funding
This early return is only possible if the channel requires a single
confirmation, allowing a `channel_ready` message to go out. This can be
problematic though if a commitment transaction (specifically from the
counterparty, as the channel would be immediately closed if a local
commitment is broadcast) also confirms within the same block. The
`ChannelMonitor` will detect both, but it won't inform the
`ChannelManager` at all. Luckily, while the channel still is considered
open to the `ChannelManager`, the `ChannelMonitor` will reject any
further updates to the channel state.
Matt Corallo [Fri, 29 Sep 2023 18:32:25 +0000 (18:32 +0000)]
Revert "Remove AvailableBalances::balance_msat"
While removing the `balance_msat` field absolutely makes sense -
it is, at best, confusing - we really need a solid replacement for
it before we can do so. While one such replacement is in progress,
it is not complete and we'd like to not block our current release
on its completion.
Wilmer Paulino [Mon, 14 Aug 2023 19:12:54 +0000 (12:12 -0700)]
Test preimage claim after reorg of counterparty commitment
This test adds coverage for receiving a preimage after seeing a
counterparty commitment confirm, followed by a reorg and the
confirmation of a different commitment instead.
The first test covers the case where a holder commitment confirms after
the counterparty commitment reorg.
The second test covers the case where a previous counterparty commitment
confirms after the latest counterparty commitment reorg.
Claim HTLCs with preimage from currently confirmed commitment
We should always claim HTLCs from the currently confirmed commitment,
rather than always claiming from the latest or previous counterparty
commitment if we've seen either confirm onchain at a prior point.
Avoid persisting on same counterparty's ChannelUpdate
Some nodes may rebroadcast their `ChannelUpdate` to their counterparty
on every connection establishment, which leads to us doing an additional
persist most of the time when nothing has changed. Now, we'll only
persist if we receive an update that changes anything.
Retrieve all possible spendable outputs from transactions
Assuming our keys haven't been compromised, and that random transactions
aren't learning of these scripts somehow and sending funds to them, it
was only possible for one spendable output to exist within a
transaction.
- `shutdown_script` can only exist in co-op close transactions.
- `counterparty_payment_script` can only exist in counterparty
commitment transactions.
- `broadcasted_holder_revokable_script` can only exist in holder
commitment/HTLC transactions.
- `destination_script` can exist in any other type of claim we support.
Now that we're exposing this API to users such that they can rescan any
relevant transactions, there's no harm in allowing them to claim more
funds from spendable outputs than we expected.
Allow retrieval of SpendableOutputDescriptors from relevant transactions
Currently, our API will only expose `SpendableOutputDescriptor`s once
after they are no longer under reorg risk (see `ANTI_REORG_DELAY`).
Users have often requested they'd like the ability to retrieve these in
some other way, either for historical purposes, or to handle replaying
any in the event of a failure.
Matt Corallo [Thu, 28 Sep 2023 18:19:36 +0000 (18:19 +0000)]
Include any recipient overpayment amounts in the route fee limit
If the user told us to limit their total fee exposure, we should
do so including any potential overpayment to the recipient, which
is ultimately a part of the "fee" as far as the user is concerned.
Matt Corallo [Tue, 26 Sep 2023 21:58:53 +0000 (21:58 +0000)]
Try to overpay the recipient if we fail to find a path at all
Previously we'd only try to overpay if we managed to find a path
to the recipient which was sufficient. However, if we fail to find
any path to the recipient at all we should still retry overpaying
the recipient. Ultimately we should be silling to pay whatever
reasonable performance penalty if the alternative is not finding a
path at all, which we do here.
Matt Corallo [Thu, 28 Sep 2023 18:19:50 +0000 (18:19 +0000)]
Allow routefinding again due to HTLC limit based on >= not >
While this doesn't matter much in practice, if we go around again
when route-finding to try to meet an htlc_minimum_msat, we use the
`recommended_value_msat` which can work if we meet the
`htlc_minimum_msat` on a channel exactly, so using >= rather than >
can capture cases with 1msat more.
Elias Rohrer [Fri, 22 Sep 2023 14:38:30 +0000 (16:38 +0200)]
Avoid adding duplicate hint candidates if they are first hops
If we have a direct channel to a node generating an invoice with route
hints, we'd previously happily add multiple candidates that all refer to
the same channel. To keep our candidate set small and unify our tracking
where possible, we now check if its `short_channel_id` is an
`outbound_scid_alias` of any of our first hops and refrain from adding
another candidate if it's the case.
Elias Rohrer [Fri, 22 Sep 2023 13:56:07 +0000 (15:56 +0200)]
Also add route hints if we are the source
Previously, we would only consider route hints if we had a direct
channel to the first node in the hint or if the first node in the hint
was part of the public network graph.
However, this left out the possiblity of us being part of the first hop,
especially if our own node is not announced and part of the graph.
Matt Corallo [Thu, 28 Sep 2023 02:40:07 +0000 (02:40 +0000)]
Refer to top-level persistence namespaces as `primary_namespace`
This fixes a bindings build error as `namespace` is a C++ keyword
which cannot be used as an argument, and while this could be fixed
in the bindings rather than here, separating the term `namespace`
between the concept (which refers to the primary and sub
namespaces) and the primary namespace makes the documentation more
readable.
Matt Corallo [Wed, 27 Sep 2023 22:26:57 +0000 (22:26 +0000)]
Use `Result<_, io::Error>` over `io::Result<_>`
Personally I've always found the overload of a prelude enum to be
confusing, and never bothered to handle it properly in bindings as
a result. To avoid needing to do so now, we simply move the
newly-introduced `io::Result` usages over to
`Result<_, io::Error>`.
Matt Corallo [Thu, 28 Sep 2023 00:46:31 +0000 (00:46 +0000)]
Don't FC when a `channel_update` has a bogus `htlc_minimum_msat`
If a peer sends us a `channel_update` for our own channel with an
`htlc_minimum_msat` which is more than the channel's amount, that's
dumb, but there's no reason to force-close the channel. We don't
even use the field.
Use correct input sequence for HTLC claims from counterparty commitments
HTLC outputs, like the `to_remote` output, in commitment transactions
with anchor outputs also have an additional `1 CSV` constraint on the
counterparty. When spending such outputs, their corresponding input
needs to have their sequence set to 1. This was done for HTLC claims
from holder commitments, but unfortunately not for counterparty
commitments as we were lacking test coverage.
get_route: fix path value contribution to include min htlc overpay
Previously, the fuzzer hit a debug panic because we wouldn't include the amount
overpaid to meet a last hop's min_htlc in the total collected paths value. We
now include this value and also penalize hops along the overpaying path to
ensure that it gets deprioritized in path selection.
get_route: fix path_min for first_hop<>network_node candidates
Previously, we would add a first_hop<>network_node channel that did not have
enough contribution amount to cover the next channel's min htlc plus fees,
because we were storing the next hop as having a path_min that did not include
fees, and would add a connecting first_hop node that did not have enough
contribution amount, leading to a debug panic upon invalid path construction.
get_route: fix path_min for first_hop<>blinded_hint candidates
See previous commit, but the bug where we would underestimate how much a first
hop candidate needed to be able to relay was also present in blinded paths.
get_route: fix path_min when adding first_hop<>route_hint candidates
Previously, we would add a candidate hop to the list of potential hops even
though its available contribution wasn't sufficient to meet the next hop's
min_htlc. We'd subsequently build an invalid path using this hop and hit a
debug assertion.
Dom Zippilli [Wed, 30 Aug 2023 00:42:07 +0000 (17:42 -0700)]
Add MonitorUpdatingPersister
MonitorUpdatingPersister is an implementation of Persister that stores
ChannelMonitorUpdates separately from ChannelMonitors. Its RFC is
in #2545, at https://github.com/orgs/lightningdevkit/discussions/2545.
Matt Corallo [Tue, 26 Sep 2023 21:28:29 +0000 (21:28 +0000)]
Set a default `max_total_routing_fee_msat` of 1% + 50sats
When using the normal default constructors, we should have some
fee maximum to ensure our default behavior is safe. Here we pick
1% + 50 sats to ensure we're always willing to pay
reasonabl(y high) fees, but not anything too wild.
Elias Rohrer [Tue, 26 Sep 2023 13:30:39 +0000 (15:30 +0200)]
Test `max_total_routing_fee_msat` handling when retrying overpaid paths
We setup an MPP scenario with two paths in which we need to overpay to
reach `htlc_minimum_msat`. We then fail the overpaid path and check that
on retry our `max_total_routing_fee_msat` only accounts for the path
fees, but not for the fees overpaid in the first attempt.