Watchtower will be supported through external signer interface
where a watchtower implementation may differ from a local one
by the scope of key access and pre-signed datas.
If any monitors are out of sync with the Channel, we previously
closed the channel, but we should really only do that if the
monitor is ahead of the channel, opting to call the whole thing
invalid if the channel is ahead of the monitor.
We delay SpendableOutputDescriptor until reaching ANTI_REORG_DELAY
to avoid misleading user wallet in case of reorg and alternative
settlement on a channel output.
Fix tests in consequence.
is_paying_spendable_output
Add ChannelMonitor::broadcasted_local_revokable_script to detect
onchain local txn paying back to us.
Fix tests in consequence
Previously, we would generate SpendableOutputDescriptor::StaticOutput
in OnchainTxHandler even if our claiming transaction wouldn't confirm
onchain, misbehaving user wallet to think it receives more funds than
in reality.
Fix tests in consequence
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).
If we call get_update_fulfill_htlc (in this case via
ChannelManager::claim_funds_internal ->
Channel::get_update_fulfill_htlc_and_commit) and it finds that we
already have a holding-cell pending HTLC claim, it will return no
monitor update but leave latest_monitor_update_id incremented.
If we later go and add a new monitor update we'll panic as the
updates appear to have been applied out-of-order.
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>
Adjusted tx occurs when a previous aggregated claim tx has
seen one of its outpoint being partially claimed by a remote tx.
To pursue claiming of the remaining outpoint a adjusted claim tx
is generated with leftover of claimable outpoints.
Previously, in case of block-rescan where a partial claim occurs,
we would generate duplicated adjusted tx, wrongly inflating feerate
for next bumps. At rescan, if input has already been dropped from
outpoints map from a claiming request, don't regenerate again
a adjuste tx.
3d640da5c3 changed the indexes for
some enums in ChannelMonitor deserialization but not serialization.
Thus, the chanmon_deser_target fuzz target failed on travis on at
least one PR.
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.
If rust-lightning tells us to disconnect a socket after we read
some bytes from the socket, but before we actually give those bytes
to rust-lightning, we may end up calling rust-lightning with a
Descriptor that isn't registered anymore.
Sadly, there really isn't a good way to solve this, and it should
be a pretty quick event, so we just busy-wait.
Failing this requirement at sending means a strict receiver would
fail our channel while processing a HTLC routed from a third-party.
Fix by enforcing check on both sender and receiver side.
This was the way DataLossProtect was originally written, however it
didn't match other implementations at the time during testing. It
turns out, other implementations didn't agree with each other
anyway (depending on the exact timeline), so the spec was clarified
somewhat in https://github.com/lightningnetwork/lightning-rfc/pull/550
. This updates us to be in line with the new guidance and appears
to solve out-of-sync issues in testing.
Fixes issue #493 and should resolve some issues where other nodes
(incorrectly) reject channel_update/node_announcement messages
which have a serial number that is not a relatively recent
timestamp.
