coin moves #3614
Didn't get too far with
It results in
In this configuration
The other configuration is the following:
Surprisingly little errors despite the chain being different. It also produces the above
For cheats, we do a little bit of weird accounting. First we 'update' our on-ledger balance to be the entirety of the channel's balance. Then, as outputs get resolved, we record the fees and outputs as withdrawals from this amount. It's possible that they might successfully 'cheat', in which case we record those as 'penalty' but debits (not credits).
We record htlcs when they're fulfilled as 'withdrawals' that are onchain. This should make use of the payment_hash that we stashed. Additionally, if an htlc spend comes through that's not ours, it's probably them resolving our attempted cheat; we should allow it to proceed without bombing, and just do our accounting as necessary. It'll all come out in the wash.
Fixes the tx type annotation in a few places.
Check that we account for push_msat and wallet withdrawal/deposits correctly
On node start we replay onchaind's transactions from the database/from our loaded htlc table. To keep things tidy, we shouldn't notify the ledger about these, so we wrap pretty much everything in a flag that tells us whether or not this is a replay. There's a very small corner case where dust transactions will get missed if the node crashes after the htlc has been added to the database but before we've successfully notified onchaind about it. Notably, most of the obtrusive updates to onchaind wrappings are due to the fact that we record dust (ignored outputs) before we receive confirmation of its confirmation.
Previously we were annotating every movement with the blockheight of lightningd at notification time. Which is lossy in terms of info, and won't be helpful for reorg reconciliation. Here we switch over to logging chain moves iff they've been confirmed. Next PR will fix this up for withdrawals, which are currently tagged with a blockheight of zero, since we log on successful send.
This moves the notification for our coin spends from when it's successfully submited to the mempool to when they're confirmed in a block. We also add an 'informational' notice tagged as `spend_track` which can be used to track which transaction a wallet output was spent in.
Changelog-Added: Plugins: new notification type, `coin_movement`, which tracks all fund movements for a node
Should make it easier to track when coin moves in the plugin are disjoint from what c-lightning says it's broadcast already.
It's possible for our peer to publish a commitment tx that has already updated our balance for an htlc before we've completed removing it from our commitment tx (aka before we've updated our balance). This used to crash, now we just update our balance (and the channel balance logs!) and keep going. If they've removed anything from our balance, we'll end up counting it as chain_fees below. Not ideal but fine... probably.
Canonicalize the signature for the 'tag-type' of coin moves by unique constructor/method calls. Suggested-By: @rustyrussell
Updates the unit of account to be the chain_id, which is the BIP173 name of the chain that the coins moved on. Suggested-By: @rustyrussell
These guys take a while to run, so let's just skip them on the valgrind/slow-machine combos :/