user136772: 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?).

user121614: 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.


136772: <p>Assuming a fork due to consensus-breaking rule change either hard-fork, UASF or similar. (So not including short reorgs.)</p>
<p>Would the channel simply become inactive/disabled and get &quot;automatically&quot; forced-closed after a while because of the disagreement between the 2 parties on the chainstate?</p>
<p>Is that handled by any BOLTs or is it let effectively as an implementation choice of the LN node developers?</p>
<p>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.</p>
<p>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?).</p>
 121614: <p>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.</p>
<p>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:</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
