Andrei [Thu, 29 Jun 2023 00:00:00 +0000 (00:00 +0000)]
Use `MonotonicTime` as `Instant` shifted by 10 years forward
Such implementation allows `MonotonicTime` to go backward up to 10
years on all platforms. On some platforms (e.g. iOS) `Instant` is
represented as `u64` of nanoseconds since the boot of the system.
Obviously such implementation does not allow to go backward before the
time of the boot.
Co-authored-by: Andrei <andrei.i@posteo.de> Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
Wilmer Paulino [Thu, 22 Jun 2023 22:19:15 +0000 (15:19 -0700)]
Require best block timestamp within ChannelManager::new
This ensures freshly initialized nodes can proceed to create unexpired
invoices without a call to `best_block_updated`, since an invoice's
expiration delta is applied to `highest_seen_timestamp`.
Wilmer Paulino [Tue, 20 Jun 2023 19:14:48 +0000 (12:14 -0700)]
Require inbound channels with anchor outputs to be accepted manually
Since the use of channels with anchor outputs requires a reserve of
onchain funds to handle channel force closures, it would be
irresponsible to allow a node to accept inbound channel without first
consulting such reserves. To allow users to do so, we require such
channels be manually accepted.
Wilmer Paulino [Tue, 20 Jun 2023 18:29:00 +0000 (11:29 -0700)]
Remove anchors config flag
Now that all of the core functionality for anchor outputs has landed,
we're ready to remove the config flag that was temporarily hiding it
from our API.
Matt Corallo [Tue, 20 Jun 2023 02:16:03 +0000 (02:16 +0000)]
Rename Channel's latest-monitor-update fetch method for clarity
`Channel::get_latest_complete_monitor_update_id` no longer refers
to complete updates, but rather ones which were passed to the
`ChannelManager` and which the `CHannel` no longer knows about.
Thus, we rename it `get_latest_unblocked_monitor_update_id`.
Matt Corallo [Mon, 19 Jun 2023 06:26:39 +0000 (06:26 +0000)]
Move in-flight `ChannelMonitorUpdate`s to `ChannelManager`
Because `ChannelMonitorUpdate`s can be generated for a
channel which is already closed, and must still be tracked
through their completion, storing them in a `Channel`
doesn't make sense - we'd have to have a redundant place to
put them post-closure and handle both storage locations
equivalently.
Instead, here, we move to storing in-flight
`ChannelMonitorUpdate`s to the `ChannelManager`, leaving
blocked `ChannelMonitorUpdate`s in the `Channel` as they
were.
Arik Sosman [Mon, 19 Jun 2023 17:30:34 +0000 (10:30 -0700)]
Replace `opt_anchors` with `ChannelTypeFeatures`
This change modifies six structs that were keeping
track of anchors features with an `opt_anchors` field,
as well as another field keeping track of nonzero-fee-
anchor-support.
Arik Sosman [Mon, 19 Jun 2023 17:28:36 +0000 (10:28 -0700)]
Define `ChannelTypeFeatures` methods for anchors logic.
Specifically, introduce a new constructor for an anchors-
supporting feature set, as well as methods that will
maintain forwards-compatible deserialization in older
versions.
Matt Corallo [Sun, 18 Jun 2023 23:56:16 +0000 (23:56 +0000)]
Simplify cases in `handle_new_monitor_update` macro
By giving up on a tiny bit of parallelism and tweaking the return
types, we can make the `handle_new_monitor_update` macro a bit
clearer - now the only cases where its called after a monitor was
updated was when the monitor was initially committed.
Matt Corallo [Sun, 18 Jun 2023 21:55:30 +0000 (21:55 +0000)]
Move most `handle_new_monitor_update` calls to pass the update
Most of the calls to the `handle_new_monitor_update` macro had the
exact same pattern - calling `update_monitor` followed by the
macro. Given that common pattern will grow to first pushing the
new monitor onto an in-flight set and then calling `update_monitor`
unifying the pattern into a single macro now avoids more code churn
in the coming commits.
Matt Corallo [Sun, 18 Jun 2023 21:18:03 +0000 (21:18 +0000)]
Return owned `ChannelMonitorUpdate`s from `Channel`
In the coming commits we'll move to storing in-flight
`ChannelMonitorUpdate`s in the `ChannelManager` rather in the
`Channel` (which will then only retain `ChannelMonitorUpdate`s
which have not yet been released/are blocked.
This will simplify handling of pending `ChannelMonitorUpdate` after
a channel has closed by not having to move them into the
`ChannelManager`.
Matt Corallo [Tue, 20 Jun 2023 17:14:21 +0000 (17:14 +0000)]
Ensure we build if a downstream crate sets `--cfg=fuzzing`
Downstream crates building fur fuzzing will usually set
`--cfg=fuzzing` as a side-effect of the Rust fuzzing tooling. Thus,
we should ensure we build without failure in such cases.
We do this here by simply relying on the `_test_utils` feature,
rather than conditionally-compiling in modules based on the
`fuzzing` flag.
Make sure the penultimate hop took the amount of fee that they claimed to take.
Without checking this TLV, we're heavily relying on the receiving wallet code
to correctly implement logic to calculate that that the fee is as expected.
Useful for penultimate hops in routes to take an extra fee, if for example they
opened a JIT channel to the payee and want them to help bear the channel open
cost.
Move PendingHTLCStatus construction inside channel lock
We need the channel lock for constructing a pending HTLC's status because we
need to know if the channel accepts underpaying HTLCs in upcoming commits.
Provide a default CoinSelectionSource implementation via a new trait
Certain users may not care how their UTXOs are selected, or their wallet
may not expose enough controls to fully implement the
`CoinSelectionSource` trait. As an alternative, we introduce another
trait `WalletSource` they could opt to implement instead, which is much
simpler as it just returns the set of confirmed UTXOs that may be used.
This trait implementation is then consumed into a wrapper `Wallet` which
implements the `CoinSelectionSource` trait using a "smallest
above-dust-after-spend first" coin selection algorithm.
This allows users to bump their commitments and HTLC transactions
without having to worry about all the little details to do so. Instead,
we'll just require that they implement the `CoinSelectionSource` trait
over their wallet/UTXO source, granting the event handler permission to
spend confirmed UTXOs for the transactions it'll produce.
While the event handler should in most cases produce valid transactions,
assuming the provided confirmed UTXOs are valid, it may not produce
relayable transactions due to not satisfying certain Replace-By-Fee
(RBF) mempool policy requirements. Some of these require that the
replacement transactions have a higher feerate and absolute fee than the
conflicting transactions it aims to replace. To make sure we adhere to
these requirements, we'd have to persist some state for all transactions
the event handler has produced, greatly increasing its complexity. While
we may consider implementing so in the future, we choose to go with a
simple initial version that relies on the OnchainTxHandler's bumping
frequency. For each new bumping attempt, the OnchainTxHandler proposes a
25% feerate increase to ensure transactions can propagate under
constrained mempool circumstances.
Wilmer Paulino [Thu, 11 May 2023 20:49:00 +0000 (13:49 -0700)]
Expose existing PackageID to API and rename to ClaimId
In a future commit, we plan to expand `BumpTransactionEvent` variants to
include the unique identifier assigned to pending output claims by the
`OnchainTxHandler` when a commitment is broadcast/confirmed. This
requires making it public in our API. We also choose to rename it to
`ClaimId` for the benefit of users, as the previous `PackageID` term
could be interpreted to be the ID of a BIP-331 transaction package.
Wilmer Paulino [Thu, 11 May 2023 22:39:13 +0000 (15:39 -0700)]
Change package ID computation for HTLC claims on anchor channels
While the previous way of computing the identifier was safe, it wouldn't
have been in certain scenarios if we considered splitting aggregated
packages. While this type of splitting has yet to be implemented, it may
come in the near future. To ensure we're prepared to handle such, we
opt to instead commit to all of the HTLCs to claim in the request.
Add CandidateRouteHop::Blinded and ::OneHopBlinded variant
It's unclear what values 1-hop blinded paths should set their BlindedPayInfos
to, because those values are meant to refer to the fees/cltv delta on the path
*between* the intro node and the destination. We zero out these values in the
new variant's methods so they don't mess with path finding/construction.
Duncan Dean [Wed, 7 Jun 2023 17:52:21 +0000 (19:52 +0200)]
Create and use methods for counting channels
This commit also adds two new maps to `PeerState` for keeping track
of `OutboundV1Channel`s and `InboundV1Channel`s so that further
commits are a bit easier to review.
Duncan Dean [Tue, 13 Jun 2023 10:34:36 +0000 (12:34 +0200)]
Prepare some methods for upcoming moves to `ChannelContext`
To reduce interleaving in commits, we introduce a `context` variable
in methods to be moved in upcoming commits so there is minimal change
with the moves.
Duncan Dean [Wed, 7 Jun 2023 10:33:41 +0000 (12:33 +0200)]
Move `Channel::get_feerate_sat_per_1000_weight` and other methods
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
Duncan Dean [Wed, 7 Jun 2023 10:26:53 +0000 (12:26 +0200)]
Move `Channel::build_holder_transaction_keys` and some other methods
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
Duncan Dean [Wed, 7 Jun 2023 10:20:25 +0000 (12:20 +0200)]
Move `Channel::build_commitment_transaction` to `ChannelContext` impl
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
Duncan Dean [Wed, 7 Jun 2023 10:15:24 +0000 (12:15 +0200)]
Move `Channel::channel_id` and some other methods to `ChannelContext` impl
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses the `context` field where needed for compilation
and tests to pass due to the above change.
Duncan Dean [Wed, 7 Jun 2023 09:57:35 +0000 (11:57 +0200)]
Move `Channel::get_update_time_counter` and some other methods
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
This commit also uses these methods through the `context` field where
needed for compilation and tests to pass due to the above change.
Duncan Dean [Wed, 7 Jun 2023 09:29:44 +0000 (11:29 +0200)]
Move `Channel::opt_anchors` to `ChannelContext` impl & move some util fns
This is one of a series of commits to make sure methods are moved by
chunks so they are easily reviewable in diffs. Unfortunately they are
not purely move-only as fields need to be updated for things to
compile, but these should be quite clear.
Duncan Dean [Tue, 7 Mar 2023 19:56:01 +0000 (21:56 +0200)]
Move `Channel` fields into `ChannelContext` struct
This is a first step for simplifying the channel state and introducing
new unfunded channel types that hold similar state before being promoted
to funded channels.
Essentially, we want the outer `Channel` type (and upcoming channel types)
to wrap the context so we can apply typestate patterns to the that wrapper
while also deduplicating code for common state and other internal fields.