This should make it a bit easier for the fuzzer to hit any given
balance breakdown during run as well as tweaks the command strings
to be more bit-pattern friendly.
Instead of simply always considering a payment-send failure as
acceptable (and aborting fuzzing), we check that a payment send
failure is from a list of errors that we know we can hit, mostly
around maxing out our channel balance.
Critically, we keep going after hitting an error, as there's no
reason channels should get out of sync even if a send fails.
Helpful for debugging. I also included the change in the provide_preimage method
signature which will be used in an upcoming commit, because commit-wise it was
easier to combine the changes.
- The ChainMonitor should:
Whenever a new channel is added or updated, these updates
should be conveyed to the persister and persisted to disk.
Even if the update errors while it's being applied, the
updated monitor still needs to be persisted.
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.
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.
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.
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.
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.
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.
ChannelManager::send_payment stopped utilizing its ownership of the
Route with MPP (which, for readability, now clone()s the individual
paths when creating HTLCSource::OutboundRoute objects). While this
isn't ideal, it likely also makes sense to ensure that the user has
access to the Route after sending to correlate individual path
failures with the paths in the route or, in the future, retry
individual paths.
Thus, the easiest solution is to just take the Route by reference,
allowing the user to retain ownership.
Base AMP is centered around the concept of a 'payment_secret` - an
opaque 32-byte random string which is used to authenticate the
sender to the recipient as well as tie the various HTLCs which
make up one payment together. This new field gets exposed in a
number of places, though sadly only as an Option for backwards
compatibility when sending to a receiver/receiving from a sender
which does not support Base AMP.
Sadly a huge diff here, but almost all of it is changing the method
signatures for sending/receiving/failing HTLCs and the
PaymentReceived event, which all now need to expose an
Option<[u8; 32]> for the payment_secret.
It doesn't yet properly fail back pending HTLCs when the full AMP
payment is never received (which should result in accidental
channel force-closures). Further, as sending AMP payments is not
yet supported, the only test here is a simple single-path payment
with a payment_secret in it.
This removes the ability to merge ChannelMonitors in favor of
explicit ChannelMonitorUpdates. It further removes
ChannelManager::test_restore_channel_monitor in favor of the new
ChannelManager::channel_monitor_updated method, which explicitly
confirms a set of updates instead of providing the latest copy of
each ChannelMonitor to the user.
This removes almost all need for Channels to have the latest
channel_monitor, except for broadcasting the latest local state.
