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
Given they are only signed by us we can RBF at wish
Fix tests broken by introduction of more txn broadcast
(channel_monitor_network_test)
Add locktime in RemoteHTLC as it's needed to generate
timeout txn.
Add RBF-bumping of justice txn, given they are only signed by us we
can RBF at wish.
Aggregation of bump-candidates and more aggresive bumping heuristics
are left open
Fix tests broken by introduction of more txn broadcast.
Some tests may have a relaxed check (claim_htlc_ouputs_single_tx)
as broadcast bumped txn are now interwining in previous broadcast ones
and breaking simple expectations
Use bumping engine to rebuild claiming transaction in case of partial-
claim of its outpoints set.
As local onchain txn are already monitored in block_connected by
check_spend_local_transaction, it's useless to generate twice
pending claims for HTLC outputs on local commitment tx.
We could do the alternative.
Add claimable_outpoints maps.
Both structures are tied and should ensure their mutual consistency.
Pending_claim_requests is cached by original claim txid. Medatada
and per input material should be constant between bumped transactions,
only change should be partial-claiming of outpoints set and block
reorgs.
Due to RBF rules, if an input has been part of an aggregate tx
at first claim try, if we want the bumped tx to land nicely
in the mempool, inputs should be distributed in multiple
bumped tx but still be aggregate in a new bumped tx.
Latency/peer disconnection may trigger us to mark as disabled
some of our channels. After some time, if channels are still
disabled we need to broadcast ChannelUpdate to inform other network
peers about the uselessness of these channels.
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.
Require to specify expected amount so that we can claim only
payment for thhe correct amount, and reject payments for incorrect
amounts (which are probably middle nodes probing to break our privacy).
Send back incorrect_or_unknown_payments_details (PERM|15) to avoid
the probe node learning that final node is waiting a payment with
the routed hash.
We also fulfilled last empty ErrorAction:
- Router secp fail : IgnoreError
- processing error in Router : IgnoreError
- get_channel_update too early : IgnoreError
