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



Summary:

The Lightning Network developers are concerned about the safety and consensus of the network during or after a fork in the underlying blockchain. The issue of how lightning nodes maintain consensus during or after a fork of the underlying blockchain has not been addressed by the BOLTs. The channel_announcement messages use a chain_hash to identify the currency in use, but it is unclear which hash identifies BTC as opposed to BCH. In terms of forks that arise after funding of a payment channel, there are concerns regarding intentional forks that rip out segwit and malicious forks that do not change their signature algorithm. These forks are impossible to defend against. However, the focus should be on forks that use strong replay protection in the form of FORKID. There are also concerns about unintentional forks, which have not yet been analyzed or designed for. The priority remains getting implementations to a safe state for deployment on Bitcoin Mainnet, adding RBF and multi-channel funding, integrating Burchert-Decker-Wattenhofer channel factories, splicing, and more. The support for altcoins can be done later. For forked altcoins, short channel IDs contain the block height at which the funding transaction confirmed, which might be used to judge if a channel contains forked coins or not. Despite concerns about system stability, the safety and resilience against forks are core to cryptocurrency safety.


Updated on: 2023-05-24T18:44:55.279781+00:00