We also update to use single idents when referencing the Deref=*
types since the automated code generator is pretty braindead.
This also moves some test utils out of peer_handler.rs and into
util::test_utils to standardize things a little bit, which we need
to concretize the PeerHandler types used in testing.
Instead of using a raw generic type, an associted type allows us
to have explicit docs on the type, which is nice. More importantly,
however, our automated bindings generator knows how to read
associated types but not raw generics.
Also, our bindings generator expects things which are referenced to
have already been defined, so we move ManyChannelMonitor below the
ChannelMonitor definition.
This is a response to splitting #585 into smaller components. This extraction will permit a future extraction of all message handling into a separate method, and then later even into a separate trait that will be accessible through language bindings.
In next commit, we add derive_channel_keys, a helper to rederive
keys from a SpendableOuptutDescriptor. We still need to ensure
that user rederive same set of keys even if KeyManager is started
at a later time. For doing so we need to pass starting time as
part of the re-derived sha_state, therefore we need to make it
accessible and part of channel state key material.
Seed is already required to be conserved between KeysManager
serializations.
As we cache more and more transaction elements in OnchainTxHandler
we should dry up completly InputMaterial until them being replaced
directly by InputDescriptor
As we can't predict if any and which revoked commitment tx is
going to appear onchain we have by design to cache all htlc information
to regenerate htlc script if needed.
This makes it easier for our automated bindings generator to
function as it tries to automatically create a ::new if the struct
contains only pub elements who's type is convertible.
This caused a bunch of cascading changes, including
passing loggers down to Channels in function calls
rather than having each Channel have a pointer to the
ChannelManager's Logger (which was a circular reference).
Other structs that the Channel had passed its Logger to also
had their loggers removed. Other newly unused Loggers were
also removed, especially when keeping them would've caused
a bunch of extra test changes to be necessary, e.g. with
the ChainWatchInterfaceUtil's Logger.
We need to always set lowest_inbound_channel_fees to None if there
are no channels (and we should ignore the channels which are
disabled for the purpose of lowest-fee calculations). Further, we
cannot unwrap the channel lookups as they may be for channels which
are not related to the channel we are processing an update for.
Finally, we can satisfy borrowck much easier since things are on
self instead of on a MutexGuard.
We previously were only able to assert that the route graph
serialization roundtrips were good by comparing the network
messages returned from them, but we can now do better as the graph
is exposed publicly via a simple datastructure that implements
PartialEq.
Because we expose the internals we don't need a method to log
their contents anymore, and get_addresses can now avoid copying as
we expose the RwLock directly
8ce2223b6952567b28adfcc11c23c9f19c4c0324 introduced a new field in
the "Node" objects used in our functional tests - the node_id. Its
not a bad idea to cache it, but unless we want to commit and use it
everywhere, we should avoid duplicating data, especially in tests
where we'd rather exercise the underlying code than bypass it.
This simplifies channelmonitor quite nicely (as expected) as we
never have to be concerned with learning data in a DataLossProtect
which is require for us to claim our funds from the latest remote
commitment transaction.
This adds the ability to check for static_remotekey in appropriate
feature contexts and prints it at connect time. It is still
considered unknown for the purposes of requires_unknown_bits() as
we don't yet implement it.
Previous to this commit, variables such as their_channel_reserve
referred to the channel reserve that _we_ are required to keep,
(the value is initially set by the remote). Similarly,
variables such as our_channel_reserve referred to the channel
reserve that we require the remote to keep.
Change this to use local_channel_reserve / remote_channel_reserve
to refer to the the channel reserve that the local is required to keep
and the channel reserve that the remote is required to keep, respectively.
It appears the local signatures which are specified in the channel
transaction-generation tests were never checked directly (though
they were checked as a part of the overall fully-signed-transaction
tests).
Check them explicitly so that they can be updated for static remote
key.
Include tests for requires_unknown_bits and supports_unknown_bits when
an unknown even bit, odd bit, or neither is set. Refactor bit clearing
such that tests and production code share the same code path. Fix a
potential spec incompatibility (currently only exposed in testing code)
where trailing zero bytes are not removed after a bit is cleared.
Converting from InitFeatures to other Features is accomplished using
Features::with_known_relevant_init_flags. Define a more general
to_context method which converts from Features of one Context to
another.
Additionally, ensure the source context only has known flags before
selecting flags for the target context.
Refactoring the features module allowed for making code specific to
certain contexts generalizable. Specifically, KNOWN_FEATURE_MASK
is defined on Context instead of hardcoded in each method
specialization. Thus, such methods are no longer required.
Features for a given context are duplicated throughout the features
module. Use a macro for defining a Context and the applicable features
such that features only need to be defined for a Context in one place.
The Context provides bitmasks for selecting known and unknown feature
flags.
BOLT 1 and BOLT 9 refer to features as "known" if a peer understands
them. They also use the term "supported" to mean either optional or
required.
Update the features module to use similar terminology.
- Define contexts in terms of required and optional features rather than
just supported features
- Define known features as those that are optional or required
- Rename supported() constructor to known()
For completeness, clear_optional_bit for each feature is now called
clear_bits and clears both optional and required bits.
Each feature is represented by two bits within Features' flags field.
Working with these flags requires bitwise operations, which can be error
prone. Rather than directly checking and manipulating bits, encapsulate
the bits within each feature trait and provide mechanisms for doing so.
This removes the need to comment on which features correspond to bitwise
expressions since the expressions use feature trait identifiers instead.
With this approach, byte literals and expressions can be evaluated at
compile time still. However, for these cases, knowing which byte within
the flags that a feature corresponds to still must be determined by the
implementor.
Remove the special case where initial_routing_sync has no even bit. Now,
it (bit 2) is considered known by the implementation.
The initial_routing_sync feature is set by peer_handler whenever a full
sync of the network graph is desired. It is not explicitly set when
creating features with InitFeatures::supported().
An upcoming refactor will change supported() to known(), which will
return all features known by the implementation. Thus, the
initial_routing_sync flag will need to be set by default. This commit
makes the behavior change ahead of the refactor.
The test_upfront_shutdown_script functional test clears this feature
flag. However, the method used to clear the flag is implemented by bit
toggling. Thus, if the flag is not set the method would actually set it.
Implement the method using bit clearing instead.
