* `PhantomRouteHints::channels` has been written since the struct
was added in 410eb05365.
* `HTLCSource::path_hops` has been written since the struct was
converted to TLVs in 66784e32fe.
* `BlindedTail::hops` has always been written since it was
introduced in 64c26c8a79.
* `PaymentParameters::clear_hints` has always been written since
it was introduced as `Payee::route_hitns` in 46b68c517d.
* `CommitmentTransaction::htlcs` has always been written since the
struct was converted to TLVs in 66784e32fe.
* `HolderCommitmentTransaction::counterparty_htlc_sigs` have always
been written since the struct was converted to TLVs in
c8bc1b6d3d.
* `PaymentPathFailed::path` was added without an optional compat
wrapper in e5310dd5f0.
* `PaymentPathSuccessful::path` has always been written since the
event was added in 2c4f16d5e3.
* `Probe{Failed,Successful}::path` have always been written since
the events were added in eb8bce0d16.
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 66784e32fe.
* `NodeInfo::channels` has been written since `NetworkGraph`
structs were converted to TLVs in 321b19c4d9.
* Several test-only TLV writes were converted.
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 85b573ddad 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.
In 1ce2beb774,
`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.
Instead, `optional_vec` must be used.
In 9dfe42cf86,
`ChannelMonitorUpdate`s were stored in `Channel` while they were
being processed. Because it was possible (though highly unlikely,
due to various locking likely blocking persistence) an update was
in-flight (even synchronously) when a `ChannelManager` was
persisted, the new updates were persisted via an odd TLV.
However, in 4041f0899f these pending
monitor updates were moved to `ChannelManager`, with appropriate
handling there. Now the only `ChannelMonitorUpdate`s which are
stored in `Channel` are those which are explicitly blocked, which
requires the async pipeline.
Because we don't support async monitor update users downgrading to
0.0.115 or lower, we move to persisting them via an even TLV. As
the odd TLV storage has not yet been released, we can do so
trivially.
Fixes#2317.
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>
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`.
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.
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.
`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`.
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.
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.
Specifically, introduce a new constructor for an anchors-
supporting feature set, as well as methods that will
maintain forwards-compatible deserialization in older
versions.
