lightning operation during / following a chain fork (e.g. BIP 50)



Summary:

The email thread discusses the topic of maintaining consensus during or after a fork of the underlying blockchain(s) in the context of lightning nodes. It is mentioned that adversarial forks that rip out segwit, or maliciously do not change their signature algorithm, are basically impossible to defend against. However, if you remove segwit, then lightning becomes unsafe, and any nodes which attempt to follow such a fork would suffer. The incentives strongly motivate maintenance of consensus, so that scenario is automatically covered and of no concern. The BOLTs as presently written explicitly require segwit2x, and for this reason, BCH is presently of no concern. The work remains on analyzing and designing solutions for handling intentional and unintentional forks. The priority is to get implementations to a state where they can safely deploy on Bitcoin Mainnet. Then optimize further by adding RBF and multi-channel funding, then integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so on. Greater support for altcoins can be done later. For forked altcoins, short channel IDs contain the block height at which the funding transaction confirmed. This might be used to judge if a channel contains forked coins or not.


Updated on: 2023-05-24T18:43:56.782535+00:00