Jesse de Wit

@joostjager I seem to end up in this piece of code [here](https://github.com/breez/lnd/blob/breez-node-v0.15.4/contractcourt/channel_arbitrator.go#L1697-L1701) for every new block for a channel that's still open. The htlc is apparently not handled. This PR...

> If the channel is still open and there are no htlcs at risk (or htlcs at risk are dust), there is no action to be taken for the channel...

> I don't think that this PR is going to help with that. It only adds reporting of the on-chain resolution to the final resolution table, but doesn't change the...

We could make a more general way for recipients to deliver data to intermediate hops, without relying on the sender to support the feature. The hop hint in the invoice...

> That would still result in an HTLC getting sent a few hops to a blinded path introduction point and then holding liquidity on those hops into the recipient comes...

> Even in that case I don't think its really acceptable - senders really need to be aware that their capital is about to be locked up for potentially-hours before...

A note for people that want to reserve message numbers for their application: Consider picking a single even/odd pair for your application and use the fist bytes of the message...

Updated the test to remove some unnecessary noise. This test appears to fail when the payment size is above half the available channel capacity. So probably the issue here is...

I haven't yet found the cause, but this stood out to me. Some logs say `Not using a routehint` Some logs say `Using routehint 0382ce59ebf18be7d84677c2e35f23294b9992ceca95491fcf8a56c6cb2d9de199 (111x1x0) cltv_delta=6` Indicating that some...

> Would it make a difference if `dest` opens a channel with `randomnode` instead of the other way around and then depleting it? That makes sense. Made that channel the...