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).
* 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`).
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.
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.
`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.
This adds a utility method, `KeysManager::spend_spendable_outputs`,
which constructs a Transaction from a given set of
`SpendableOutputDescriptor`s, deriving relevant keys as needed.
It also adds methods which can sign individual inputs where
channel-specific key derivation is required to
`InMemoryChannelKeys`, making it easy to sign transaction inputs
when a custom `KeysInterface` is used with `InMemoryChannelKeys`.
Previously, test_dynamic_spendable_outputs_local_htlc_success_tx
called connect_block with two identical transactions, which
resulted in duplicate SpendableOutputs Events back-to-back. This
is a test issue as such a block_connected call represents an
invalid block.
KeyManager::new() took a bitcoin::Network parameter which needs to
be passed to the BIP 32 Extended Key constructor, but because we
never write out the BIP 32 serialization, it isn't used. Instead,
we just pass a dummy value into `ExtendedPrivKey`, dropping the
unused argument to KeysManager::new().
Both SpendableOutputDescriptor::DynamicOutputP2WSH and
SpendableOutputDescriptor::StaticOutputCounterpartyPayment are
relevant only in the context of a given channel, making them
candidates for being passed into helper functions in
`InMemoryChannelKeys`. This moves them into their own structs so
that they can later be used standalone.
We previously counted 35 bytes for a length + public key, but in
reality they are never larger than 34 bytes - 33 for the key and 1
for the push length.
Sadly rust upstream never really figured out the benchmark story,
and it looks like the API we use here may not be long for this
world. Luckily, we can switch to criterion with largely the same
API if that happens before upstream finishes ongoing work with the
custom test framework stuff.
Sadly, it requires fetching the current network graph, which I did
using Val's route-testing script written to test the MPP router.
This adds a channel_value_satoshis field to
SpendableOutputDescriptors as it is required to recreate our
InMemoryChannelKeys. It also slightly expands documentation.
Instead of `key_derivation_params` being a rather strange type, we
call it `channel_keys_id` and give it a generic 32 byte array. This
should be much clearer for users and also more flexible.
The only API change outside of additional derives is to change
the inner field in `DecodeError::Io()` to an `std::io::ErrorKind`
instead of an `std::io::Error`. While `std::io::Error` obviously
makes more sense in context, it doesn't support Clone, and the
inner error largely doesn't have a lot of value on its own.
When we receive an error message from a peer, it can indicate a
channel which we should close. However, we previously did not
check that the counterparty who sends us such a message is the
counterparty with whom we have the channel, allowing any
connected peer to make us force-close any channel we have as long
as they know the channel id.
This commit simply changes the force-close logic to check that the
sender matches the channel's counterparty node_id, though as noted
in #105, we eventually need to change the indexing anyway to allow
absurdly terrible peers to open channels with us.
Found during review of #777.
This (finally) exposes `ChannelManager`/`ChannelMonitor` _write
methods, which were (needlessly) excluded as the structs themselves
have generic parameters. Sadly, we also now need to parse
`(C-not exported)` doc comments on impl blocks as we otherwise try
to expose _write methods for `&Vec<RouteHop>`, which doesn't work
(and isn't particularly interesting for users anyway). We add such
doc comments there.
`CommitmentTransaction::new_with_auxiliary_htlc_data()` includes a
unbounded generic parameter which we can't concretize and it's of
limited immediate use for users in any case. We should eventually
add a non-generic version which uses `()` for the generic but that
can come later.
`CommitmentTransaction::htlcs()` returns a reference to a Vec,
which we cannot currently map. It should, however, be exposed to
users, so in the future we'll need to have a duplication function
which returns Vec of references or a cloned Vec.
