Given the chain::Watch interface is defined in terms of ChannelMonitor
and ChannelMonitorUpdateErr, move channelmonitor.rs from the ln module
to the chain module.
WatchEventProvider served as a means for replacing ChainWatchInterface.
However, it requires users to explicitly fetch WatchEvents, even if not
interested in them. Replace WatchEventProvider by chain::Filter, which
is an optional member of ChainMonitor. If set, interesting transactions
and output spends are registered such that blocks containing them can be
retrieved from a chain source in an efficient manner.
This is useful when the chain source is not a full node. For Electrum,
it allows for pre-filtered blocks. For BIP157/158, it serves as a means
to match against compact filters.
BlockNotifier was removed in the previous commit, thus ChainListener is
no longer needed. Instead, anything needing chain events should be
notified directly.
ChainMonitor's template Key parameter was meant to allow supporting
both local monitoring, where Key=OutPoint, and watchtowers, where Key=
(PublicKey, u32). Use OutPoint directly since the watchtower case will
not be supported this way.
ManyChannelMonitor was renamed chain::Watch in the previous commit. Use
a more concise name for an implementation that monitors the chain for
channel activity. Future work will parameterize the struct to allow for
different varieties of persistence. Thus, users usually will be able to
use ChainMonitor directly rather than implementing a chain::Watch that
wraps it.
Rename ManyChannelMonitor to chain::Watch and move to chain/mod.rs,
where chain-related interfaces live. Update the documentation for
clarity and to conform to rustdoc formatting.
ChainWatchInterface was intended as an interface for watching rather
than accessing the chain. Remove get_chain_utxo and add chain::Access
trait for this behavior. Wrap it with an Option in NetGraphMsgHandler in
order to simplify the error interface.
Use of ChainWatchInterface was replaced with WatchEvent in the previous
commit. Remove it from the parameterization of SimpleManyChannelMonitor
since it is no longer needed.
ChainListeners should be independent of each other, but in practice this
is not the case because ChainWatchInterface introduces a dependency
between them. Push ChainWatchInterface down into the ChainListener
implementations where needed. Update ChainListener's block_connected
method to take a slice of the form &[(usize, &Transaction)] where each
transaction is paired with its position within the block.
Its somewhat awkward that ChannelManagerReadArgs requires a mutable
reference to a HashMap of ChannelMonitors, forcing the callsite to
define a scope for the HashMap which they almost certainly won't use
after deserializing the ChannelManager. Worse, to map the current
version to C bindings, we'd need to also create a HashMap binding,
which is overkill for just this one use.
Instead, we just give the ReadArgs struct ownership of the HashMap
and add a constructor which fills the HashMap for you.
Because the C bindings maps objects into new structs which contain
only a pointer to the underlying (immovable) Rust type, it cannot
create a list of Rust types which are contiguous in memory. Thus,
in order to allow C clients to call certain Rust functions, we have
to use &[&Type] not &[Type]. This commit fixes this issue for the
get_route function.
To do this, we replace get_and_clear_pending_htlcs_updated with
get_and_clear_pending_monitor_events, and which still transmits HTLCUpdates
as before, but now also transmits a new MonitorEvent::CommitmentTxBroadcasted
event when a channel's commitment transaction is broadcasted.
Due to a desire to be able to override temporary channel IDs and
onion keys, KeysInterface had two separate fetch-random-32-bytes
interfaces - an onion-key specific version which fetched 2 random
32 byte strings and a temporary-channel-id specific version.
It turns out, we never actually need to override both at once (as
creating a new channel and sending an outbound payment are always
separate top-level calls), so there's no reason to add two
functions to the interface when both really do the same thing.
This changes the LICENSE file and adds license headers to most files
to relicense under dual Apache-2.0 and MIT. This is helpful in that
we retain the patent grant issued under Apache-2.0-licensed work,
avoiding some sticky patent issues, while still allowing users who
are more comfortable with the simpler MIT license to use that.
See https://github.com/rust-bitcoin/rust-lightning/issues/659 for
relicensing statements from code authors.
We use them largely as indexes into a Vec<Transaction> so there's
little reason for them to be u32s. Instead, use them as usize
everywhere.
We also take this opportunity to add range checks before
short_channel_id calculation, as we could otherwise end up with a
bogus short_channel_id due to an output index out of range.
This was just an oversight when route calculation was split up into
parts - it makes no sense for get_route to require that we have a
full route message handler, only a network graph (which can always
be accessed from a NetGraphMsgHandler anyway).
Instead of making the filter_block fn in the ChainWatchInterface
trait return both a list of indexes of transaction positions within
the block and references to the transactions themselves, return
only the list of indexes and then build the reference list at the
callsite.
While this may be slightly less effecient from a memory locality
perspective, it shouldn't be materially different.
This should make it more practical to generate bindings for
filter_block as it no longer needs to reference Rust Transaction
objects that are contained in a Rust Block object (which we'd
otherwise just pass over the FFI in fully-serialized form).
When we were sending an open_channel messages we were asking the
feerate estimator for a new value instead of using the one we had.
If the feerate estimator gave a different value than the one it did
when we created the Channel struct, we'd start out-of-sync with our
counterparty and blow up on funding_signed. Even worse, the
ConfirmationTarget used was different, so its highly likely they
would disagree.
Also remove newly unused fee estimator parameter from get_open-channel
API.
Co-authored-by: Matt Corallo <git@bluematt.me>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
A dynamic-p2wsh-output like `to_local` on local commitment/HTLC txn
require a signature from delayed_payment_key to be spend. Instead of
sending private key in descriptor, we ask for spender to derive again
the corresponding ChannelKeys based on key state, uniquely identifying
a channel and encompassing its unique start data.
Descriptor modification is done in next commit.
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 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.
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.
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.
