What would happen to a LN channel if one of the parties followed a minority fork of Bitcoin?

Question

Assuming a fork due to consensus-breaking rule change either hard-fork, UASF or similar. (So not including short reorgs.)

Would the channel simply become inactive/disabled and get "automatically" forced-closed after a while because of the disagreement between the 2 parties on the chainstate?

Is that handled by any BOLTs or is it let effectively as an implementation choice of the LN node developers?

EDIT: One very common scenario that may affect the answer is the following. Channel parties continuously update the force-closing commitments of the channel to account for the latest fee rates, this is done automatically by the nodes very often, without the node owners initiating it. A similar scenario is routing a payment for others.

Unless in all the core LN material interactions (send payment, receive payment, route payment, update channel state, update unilateral closing commitments) there isn't a need for the two parties to agree on the same chaintip beforehand, it seems the nodes could keep transacting while one node assumes BTCmain and the other BTCfork. And only when one of them tries to close/settle the channel will the issue will be identified (depending on replay-protection and maybe the block height difference?).

Answer 1

A LN channel (in its current form) is a 2-of-2 multisig UTXO coupled with pre-signed transactions each channel party holds onto, either to force-close the channel or to punish the other party for publishing an old state.

Following a hard fork, the UTXO will continue existing on the new chain, but the transactions will no longer be valid (assuming the new chain has replay protection). So in the event of an impending hard fork, either situation would occur for each channel:

• The channel parties would sign and exchange transactions valid on the new chain in advance in order to either continue operating it or to cooperatively close it once the fork happens.
• The parties would not agree to do the above, and one of them would close the channel in advance in order to be able to claim the forked coins.
• The parties would assume the value lost in ignoring the new chain is not worth the hassle and do nothing. If they later agreed, they could still cooperatively spend the UTXO.

Answer 2

I doubt that any effort has been spent on mitigating such a fork scenario so far. Generally, the relevant questions are:

• Do the two networks both persist, remain irreconcilable, and maintain meaningful value going forth?
• Are transactions replayable between the two chaintips?
• Do the relevant Lightning implementations support both networks?

Nothing happens automatically in Lightning, any action has to be initiated by one of the two channel owners.

I would expect the most likely outcome to be that one side would initiate a channel closing at some point, and that leading to a collaborative channel closure on one or both networks as long as the parties are still communicating.

If transactions are replayable between the two networks, even a unilateral channel closing attempt would propagate to both networks as we've seen in previous fork events that replayable transactions do get replayed. So even if the channel owners are not in touch, a unilateral close should have the expected outcome on both chains. Possibly the justice transaction would only get confirmed on one network because feerates are too divergent but the defender only cares about one network.

If one party doesn't care about the other network and transactions are not replayable or only uni-directionally replayable, perhaps one party could succeed at publishing an old state without the breach remedy being applied. Possibly Lightning software would need to get patched in that case to be able to create closing transactions on the other network. Since Lightning relies on pre-signed transactions, in that case maybe only a collaborative close would be possible and the funds would be lost on the chain that changed its transaction format because one of the owners does not care about it.

Either way, each fork would eventually bootstrap its own distinct network after the dust settles. The Lightning spec already prescribes that channels be labeled with the network they belong to, so once replayability and network identifiers are sorted the Lightning networks shouldn't cause conflicts further.