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.
Eventually, we want to remove the Channel's copy of its own
ChannelMonitor, reducing memory footprint and complexity of
ChannelManager greatly.
This removes the last uses of said ChannelMonitor for latest
local commitment transactions (though it is still used for
would_broadcast_at_height(), which is the last remaining use).
Bumping of justice txn on revoked HTLC-Success/HTLC-timeout is triggered
until our claim is confirmed onchain with at least
ANTI_REORG_DELAY_SAFE. Before this patch, we weren't tracking them in
check_spend_remote_htlc, leading us to infinite bumps.
Fix#411
Small fixes by Matt Corallo <git@bluematt.me>
Enforce a minimum htlc_minimum_msat of 1.
Instead of computing dynamically htlc_minimum_msat based on feerate,
relies on user-provided configuration value. This let user compute
an economical-driven channel parameter according to network dynamics.
This is a somewhat-obvious oversight in the capabilities of
rust-lightning, though not a particularly interesting one until we
start relying on node_features (eg for variable-length-onions and
Base AMP).
Sadly its not fully automated as we don't really want to store the
list of available addresses from the user. However, with a simple
call to ChannelManager::broadcast_node_announcement and a sensible
peer_handler, the announcement is made.
This reintroduces a check_spends!() removed in 3d640da5c3
due to check_spends not being able to check a transaction which
spends multiple other transactions.
It also simplifies a few calls in claim_htlc_outputs_single_tx by
using check_spends!().
The API to rust-bitcoin to check a transaction correctly spends
another changed some time ago, but we still have a lot of needless
.clone()s in our tests.
This tests Router serialization round-trip at the end of each
functional test in the same way we do ChannelMonitors and
ChannelManagers to catch any cases where we were able to get into
a state which would have prevented reading a Router back off disk.
We further walk all of the announcements which both the original
and deserialized Routers would send to peers requesting initial
sync to ensure they match.
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.
Previously, when attempting to write out a channel with some
RemoteAnnounced pending inbound HTLCs, we'd write out the count
without them, but write out some of their fields. We should drop
them as intended as they will need to be reannounced upon
reconnection.
This was found while attempting to simply reproduce a different
bug by adding tests for ChannelManager serialization rount-trip at
the end of each functional_test (in Node::drop). That test is
included here to prevent some classes of similar bugs in the future.
This tests, after each functional test, that if we serialize and
reload all of our ChannelMonitors we end up tracking the same set
of outputs as before.
Previously, if new ouputs were found to be watched as part
of channel operations, the block was rescan which triggers
again parser and generation of transactions already issued.
This commit first modifies the test framework without
altering further ChannelMonitor.
ChannelMonitor refactoring is introduced in a latter commit.
Additional changes:
* Update fuzz crate to match ChannelManager's new API
* Update lightning-net-tokio library to match ChannelManager's new ChannelMonitor Deref API
* Update tests to match ChannelManager's new ChannelMonitor Deref API
Fix a crash where previously we weren't able to detect any accepted
HTLC if its witness-encoded cltv expiry was different from expected
ACCEPTED_HTLC_SCRIPT_WEIGHT. This should work for any cltv expiry
included between 0 and 16777216 on mainnet, testnet and regtest.
This merges local and global features into one struct, which is
parameterized by where it appers. The parameterization restricts
which queries can be made and which features can be set, in line
with the latest BOLT 9.
Closes#427.
Simplify interfaces between ChannelMessageHandler and PeerManager,
by switching all ChannelMessageHandler errors to HandleError sent
internally instead of being return. With further refactors in Router
and PeerChannelEncryptor, errors management on the PeerManager-side
won't be splitted between try_potential_handleerror and HandleError
processing.
Inside ChannelManager, we now log MsgHandleErrInternal and send
ErrorAction to PeerManager.
On a high-level, it should allow client using API to be more flexible
by polling events instead of waiting function call returns.
We also update handle_error macro to take channel_state_lock from
caller which should avoid some deadlock potential for some edges
cases.
Filter out IgnoreError in handle_error macro, update test in
consequence.
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
A pending claim request may contain a set of multiple outpoints.
If one or multiple of them get claimed by remote party, our in-flight
claiming transactions aren't valid anymore so we need to react
quickly and regenerate claiming transaction with accurate set.
However, a claimed outpoint may be disconnected and we need to resurrect
back outpoint among set of orignal pending claim request.
To guarantee consistency of contentious claimed outpoint we cache it
as OnchainEvent::ContentionsOutpoint and only delete it after
ANTI_REORG_DELAY.
Fix test broken by change, partial claiming on revoked txn
force us to regenerate txn
Because filter_block takes a and returns a list of s , we must add a lifetime to the ChainWatchInterface, which bubbles up in a lot of places. These places include adding a lifetime to the Node struct, which causes a lot of rearranging tests so that variables don't go out of scope before the Node that owns them does.
Adding this struct will allow us to remove the circular reference
between ChainListeners and the ChainWatchInterface, because it
separates out the responsibility of notifying listeners about new
blocks from the responsibility of storing and retrieving watched
transactions.
This includes the purpose of this PR, which is to remove the circular reference created by ChainListeners self-adding themselves to their ChainWatchInterface's `listeners` field.
