In testing, its useful to be able to tell the `SocketDescriptor` to
pretend the system network buffer is full, which we add here by
creating a new `hang_writes` flag. In order to simplify
constructing, we also add a new constructor which existing tests
are moved to.
When our `ChannelMessageHandler` creates gossip broadcast
`MessageSendEvent`s, we generally want these to be reliably
delivered to all our peers, even if there's not much buffer space
available.
Here we do this by passing an extra flag to `forward_broadcast_msg`
which indicates where the message came from, then ignoring the
buffer-full criteria when the flag is set.
This renames the field in `PackageTemplate` which describes the
height at which a counterparty can make a claim to an output to
match its actual use.
Previously it had been set based on when a counterparty can claim
an output but also used for other purposes. In the previous commit
we cleaned up its use for fee-bumping-rate, so here we can rename
it as it is now only used as the `counteraprty_spendable_height`.
`PackageTemplate::get_height_timer` is used to decide when to next
bump our feerate on claims which need to make it on chain within
some window. It does so by comparing the current height with some
deadline and increasing the bump rate as the deadline approaches.
However, the deadline used is the `counterparty_spendable_height`,
which is the height at which the counterparty might be able to
spend the same output, irrespective of why. This doesn't make sense
for all output types, for example outbound HTLCs are spendable by
our counteraprty immediately (by revealing the preimage), but we
don't need to get our HTLC timeout claims confirmed immedaitely,
as we actually have `MIN_CLTV_EXPIRY` blocks before the inbound
edge of a forwarded HTLC becomes claimable by our (other)
counterparty.
Thus, here, we adapt `get_height_timer` to look at the type of
output being claimed, and adjust the rate at which we bump the fee
according to the real deadline.
Now that we don't store the confirmation height of the inputs
being spent, passing the current height to
`PackageTemplate::build_package` is useless - we only use it to set
the height at which we should next bump the fee, but we just want
it to be "next block", so we might as well use `0` and avoid the
extra argument. Further, in one case we were already passing `0`,
so passing the argument is just confusing as we can't rely on it
being set.
Note that this does remove an assertion that we never merge
packages that were crated at different heights, and in the future
we may wish to do that (as there's no specific reason not to), but
we do not currently change the behavior.
This has never been used, and its set to a fixed value of zero for
HTLCs on local commitment transactions making it impossible to rely
on so might as well remove it.
Previously, we used the `bdk_macros` dependency for some simple proc
macros in `lightning-transaction-sync`. However, post-1.0 BDK doesn't
further maintain this crate and will at some point probably yank it
together with the old `bdk` crate that was split up.
Here, we create a new crate for utility proc macros and ~~steal~~ add
what we currently use (slightly modified for the latest `syn` version's
API though). In the future we may want to expand this crate, e.g., for
some `maybe_async` macros in the context of an `async KVStore`
implementation.
If we manage to pull a `node_counter` from `removed_node_counters`
for reuse, `add_channel_between_nodes` would `unwrap_or` with the
`next_node_counter`-incremented value. This visually looks right,
except `unwrap_or` is always called, causing us to always increment
`next_node_counter` even if we don't use it.
This will result in the `node_counter`s always growing any time we
add a new node to our graph, leading to somewhat larger memory
usage when routing and a debug assertion failure in
`test_node_counter_consistency`.
The fix is trivial, this is what `unwrap_or_else` is for.
This function was very confusing - its used to determine by when
we have to stop aggregating this claim with others as it starts to
be at risk of pinning due to the counterparty's ability to spend
the output.
It is not ever used as a timelock for a transaction, and thus its
name is very confusing.
Instead we rename it `counterparty_spendable_height`.
We don't actually care if a confirmed transaction claimed other
outputs, only that it claimed a superset of the outputs in the
pending claim we're looking at. Thus, the variable to detect that
is renamed `is_claim_subset_of_tx` instead of `are_sets_equal`.
This reverts commit 85eb8145fb.
Logging here can be overly verbose and moreover in case of event
handling failure, we loop back without any added delay.
Previously, the `ChainListenerSet` `Listen` implementation wouldn't
forward to the listeners `block_connected` implementation outside of
tests. This would result in the default implementation of
`Listen::block_connected` being used and the listeners implementation
never being called.
Users commonly want to know what their balance was when a channel
was closed, which this provides in a somewhat simplified manner.
It does not consider pending HTLCs and will always overstate our
balance by transaction fees.
When we serialize from a byte array to bech32 in
`lightning-invoice`, we can either copy the array itself into the
iterator or hold a reference to the array and iterate through that.
In aa2f6b47df we opted to copy the
array into the iterator, which is fine for the current array sizes
we're working with, but does result in additional memory on the
stack if, in the future, we end up writing large arrays.
Instead, here, we switch to using the slice serialization code when
writing arrays, (very marginally) reducing code size and reducing
stack usage.
In aa2f6b47df we refactored
`lightning-invoice` de/serialization to use the new version of
`bech32`, but in order to keep the public API the same we
introduced one allocation we could have skipped.
Instead, here, we replace the public `Utf8Error` with
`FromUtf8Error` which contains the original data which failed
conversion, removing an allocation in the process.
In aa2f6b47df we refactored
`lightning-invoice` de/serialization to use the new version of
`bech32`, but ended up adding one unnecessary allocation in our
offers logic, which we drop here.
In aa2f6b47df we refactored
`lightning-invoice` de/serialization to use the new version of
`bech32`, also reducing some trivial unnecessary allocations when
we did so.
Here we drop a few additional allocations which came up in review.
A `DNSResolverMessageHandler` which handles resolution requests
should want the `NodeFeatures` included in the node's
`node_announcement` to include `dns_resolver` to indicate to the
world that it provides that service. Here we enable this by
requesting extra feature flags from the `DNSResolverMessageHandler`
in the features `OnionMessenger`, in turn, provides to
`PeerManager` (which builds the `node_announcement`).
This feature bit is used to indicate that a node will make DNS
queries on behalf of onion message senders, returning DNSSEC TXT
proofs for the requested names.
It is used to signal support for bLIP 32 resolution and can be used
to find nodes from which we can try to resolve BIP 32 HRNs.
