Calling update_witnesses in a lightning wallet may disrupt channel operations

[St333p]

A LN node needs to call update_witnesses from time to time, for instance to handle force closures (i.e. broadcasting a commitment TX) or blockchain reorgs. If one of such calls happens while an HTLC payment is happening, it may make it fail. This happens because commitment transactions are all set to Archived, making it impossible for the RGB wallet to spend their allocation in the corresponding HTLC TX.

[dr-orlovsky]

Just use witness resolver which does the right thing. LN nodes were supposed to have a custom witness resolver

[St333p]

Just use witness resolver which does the right thing. LN nodes were supposed to have a custom witness resolver

Should that witness resolver be used when calling update_witnesses? This would require the node to store at least the last commitment transaction id for every open channel and instruct the resolver to leave them in tentative status.

Maybe it would be easier to introduce a new WitnessOrd::Offchain (or Ignored, we can discuss the name), which is mostly equivalent to Tentative, but witnesses in this state are ignored by update_witnesses. At that point we would also need a force_update_witness method since, in case of a force close, a commitment tx should go from WitnessOrd::Offchain to Tentative/Mined. This would have the important upside that high-frequency channels wouldn't pose a performance burden on calls to update_witnesses.

[dr-orlovsky]

I do not know which approach is better... The complexity will come in a fact that HTLC assignments will have commitment tx as their witness, and in v0.11 you can't have account for deeper witnesses, so everything could be very messy...

I prefer v0.12 where a very different approach is used and we account all witnesses in the history with roll-back procedure...

[St333p]

I think we will try to implement the approach I described on the v0.11 so that we'll be able to evaluate the involved complexity on an open PR. Worst case it will be a waste of time if we end up choosing to go on v0.12.