Author: Benjamin Mord 2018-01-30 16:41:09
Published on: 2018-01-30T16:41:09+00:00
The discussion revolves around two different topics: adversarial forks and segwit as a fix to transaction malleability. Lightning becomes unsafe if segwit is removed, as it reintroduces the txid malleability bug. Any nodes following such a fork would suffer, but incentives strongly motivate maintenance of consensus. BOLTs explicitly require segwit2x for this reason. An "adversarial" fork refers to one that lacks replay protection, which can be addressed using strong replay protection in the form of FORKID. Ben expresses concern about safety despite BIP 50 scenarios, forks with more legitimate contention than seen so far, and system stability in the face of an increasingly unsophisticated/gullible user base. He believes that resilience against forks is critical to safety, but it seems circular to assume consensus in its design, particularly when there are entities financially motivated to fracture that consensus. The rough consensus among most Lightning developers is that BTC is "the real BTC" and gets the Satoshi genesis hash, while BCH is an altcoin that was forked off BTC and gets as a hash the branching-off point. The work on handling intentional and unintentional forks remains, but currently, the priority is to safely deploy implementations on Bitcoin Mainnet. Short channel IDs contain the block height at which the funding transaction confirmed, and this might be used to judge if a channel contains forked coins or not.
Updated on: 2023-05-24T18:45:39.997295+00:00