Define a separate trait akin to chain::Listen for notifying when
transactions have been confirmed on chain or unconfirmed during a chain
reorganization. Whereas chain::Listen is used for block-oriented chain
sources, chain::Confirm is used for chain sources supplying data for
activity related to transactions and outputs registered via
chain::Filter.
Define an Electrum-friendly interface for ChannelMonitor where txids of
relevant transactions can be obtained. For any of these transactions
that are re-orged out of the chain, users must call
transaction_unconfirmed.
When using Electrum, transactions are individually unconfirmed during a
reorg rather than by block. Store the txid of the transaction creating
the on-chain event so that it can be used to determine which events need
to be removed when a transaction is unconfirmed.
Rather than mapping height to a vector of events, use a single vector
for all events. This allows for easily processing events by either
height or transaction. The latter will be used for an interface suitable
for Electrum.
The generic methods prevent Sign from being a dyn object.
Use Secp256k1<All> as part of removing generics from Secp256k1 contexts passed into Sign methods.
chain::Filter::register_output may return an in-block dependent
transaction that spends the output. Test the scenario where the txdata
given to ChainMonitor::block_connected includes a commitment transaction
whose HTLC output is spent in the same block but not included in txdata.
Instead, it is returned by chain::Filter::register_output when given the
commitment transaction's HTLC output. This is a common scenario for
Electrum clients, which provided filtered txdata.
Electrum clients will only provide transaction data for outputs that
have been explicitly registered. Hence, upon registering new outputs,
recursively register any outputs to watch contained within dependent
transactions from the same block.
When registering a watched transaction output, any in-block descendant
transactions spending the output must be supplied. Give the block hash
when registering such outputs such that this is possible. Otherwise,
spends from other blocks may be returned inadvertently.
Electrum clients primarily operate by subscribing to notifications of
transactions by script pubkeys. Therefore, they will send filtered
transaction data without including dependent transactions. Outputs for
such transactions must be explicitly registered with these clients.
Therefore, upon block_connected, provide a mechanism for an Electrum-
backed chain::Filter to return new transaction data to scan.
`get_outputs_to_watch` returned a reference to an existing
`HashMap` avoiding extra clones, but there isn't a huge reason to
do so now that we have to clone to copy it out of the
`ChannelMonitor` mutex. Instead, return a `Vec` since it may be
less memory and it allows us to have a bindings C mapping for the
function.
Co-authored-by: Jeffrey Czyz <jkczyz@gmail.com>
Co-authored-by: Matt Corallo <git@bluematt.me>
The deserialization process for `ChannelManager`/`ChannelMonitor`
data includes reloading any relevant `chain::Filter` with data
provided from the `ChannelMonitor`, but its nice if we adapt the
data to `chain::Filter` calls for users.
When a block is disconnected, the hash of the disconnected block was
used to update the last connected block. However, this amounts to a
no-op because these hashes should be equal. Successive disconnections
would update the hash but leave it one block off.
Normally, this not a problem because the last block_disconnected should
be followed by block_connected since the former is triggered by a chain
re-org. However, this assumes the user calls the API correctly and that
no failure occurs that would prevent block_connected from being called
(e.g., if fetching the connected block fails).
Instead, update the last block hash with the disconnected block's
previous block hash.
ChannelMonitor keeps track of the last block connected. However, it is
initialized with the default block hash, which is a problem if the
ChannelMonitor is serialized before a block is connected. Instead, pass
ChannelManager's last_block_hash, which is initialized with a "birthday"
hash, when creating a new ChannelMonitor.
The implementation of chain::Listen for ChannelMonitor required using a
RefCell since its block_connected method required a mutable borrow. This
is no longer the case since ChannelMonitor now uses interior mutability
via a Mutex. So the RefCell is no longer needed.
Now that ChannelMonitor uses an internal Mutex to support interior
mutability, ChainMonitor can use a RwLock to manage its ChannelMonitor
map. This allows parallelization of update_channel operations since an
exclusive lock only needs to be held when adding to the map in
watch_channel.
ChainMonitor accesses a set of ChannelMonitors behind a single Mutex.
As a result, update_channel operations cannot be parallelized. It also
requires using a RefCell around a ChannelMonitor when implementing
chain::Listen.
Moving the Mutex into ChannelMonitor avoids these problems and aligns it
better with other interfaces. Note, however, that get_funding_txo and
get_outputs_to_watch now clone the underlying data rather than returning
references.
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).
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`).
