Add a utility for syncing a set of chain listeners to a common chain
tip. Required to use before creating an SpvClient when the chain
listener used with the client is actually a set of listeners each of
which may have had left off at a different block. This would occur when
the listeners had been persisted individually at different frequencies
(e.g., a ChainMonitor's individual ChannelMonitors).
Adds a lightweight client for polling one or more block sources for the
best chain tip. Notifies listeners of blocks connected or disconnected
since the last poll. Useful for keeping a Lightning node in sync with
the chain.
Add an interface for being notified of block connected and disconnected
events, along with a notifier for generating such events. Used while
polling block sources for a new tip in order to feed these events into
ChannelManager and ChainMonitor.
ChainPoller defines a strategy for polling a single BlockSource. It
handles validating chain data returned from the BlockSource. Thus, other
implementations of Poll must be defined in terms of ChainPoller.
SPV clients need to poll one or more block sources for the best chain
tip and to retrieve related chain data. The Poll trait serves as an
adaptor interface for BlockSource. Implementations may define an
appropriate polling strategy.
* Implemented protocol.
* Made feature optional.
* Verify that the default value is true.
* Verify that on shutdown,
if Channel.supports_shutdown_anysegwit is enabled,
the script can be a witness program.
* Added a test that verifies that a scriptpubkey
for an unreleased segwit version is handled successfully.
* Added a test that verifies that
if node has op_shutdown_anysegwit disabled,
a scriptpubkey with an unreleased segwit version on shutdown
throws an error.
* Added peer InitFeatures to handle_shutdown
* Check if shutdown script is valid when given upfront.
* Added a test to verify that an invalid test results in error.
* Added a test to check that if a segwit script with version 0 is provided,
the updated anysegwit check detects it and returns unsupported.
* An empty script is only allowed when sent as upfront shutdown script,
so make sure that check is only done for accept/open_channel situations.
* Instead of reimplementing a variant of is_witness_script,
just call it and verify that the witness version is not 0.
The `ChannelKeys` object really isn't about keys at all anymore,
its all about signing. At the same time, we rename the type aliases
used in traits from both `ChanKeySigner` and `Keys` to just
`Signer` (or, in contexts where Channel isnt clear, `ChanSigner`).
Other includes calling timer_chan_freshness_every_minute() and in the
future, possibly persisting channel graph data.
This struct is suitable for things that need to happen periodically and
can happen in the background.
This will allow the ChannelManager to signal when it has new
updates to persist, and adds a way for ChannelManager persisters
to be notified when they should re-persist the ChannelManager
to disk/backups.
Feature-gate the wait_timeout function because the core
lightning crate shouldn't depend on wallclock time unless
users opt into it.
`from_c_conversion_container_new_var` should use var_access when
it wishes to access the variable being converted, not `var_name`,
but in a few cases it did not. Note that this has no impact on the
generated bindings as of this commit.
Sadly, there's just not really a practical way to map a slice of
objects in our current bindings infrastructure - either we take
ownership of the underlying objects and move them into a Vec, or we
need to leave the original objects in place and have a list of
pointers to the Rust objects. Thus, the only practical mapping is
to create a slice of references using the pointers we have.
This handles, for example, the `impl<X: Y> for Features<X>` blocks
which are generic across a number of different contexts. We do so
by walking the set of structs which alias Features and then walking
their generic arguments to check that they meet the bounds
specified in the impl block. For each alias which does, we create
a dummy, explicit, `impl XFeatures` block with the same content as
the original and recurse.
We already map type aliases which alias private types as opaque,
but we don't resolve them like we would any other opaque type,
preventing conversion printing or type use.
`Result` is in the standard prelude, so no need to ever use it.
Sadly, returning a Features<T> in the `impl Futures {}` block
will confuse our new alias-impl-printing logic, as we end up
running through the normal impl-block-printing logic as if we had
an explicit `impl ConcreteFeatures` block.
