Published on: 2017-08-17T13:38:26+00:00
The conversation among Bitcoin developers revolves around the issue of payment channels during hardforks. Payment channels are not a concern for hardforks like Bitcoin ABC without a malleability fix. However, in the case of a hardfork with a malleability fix, replay protection is needed to prevent problems. One possible solution is to timestamp commitments and integrate them into the channel design. By accepting only old commitments for a certain period of time, this replay protection can be reused for future hardforks. However, hardforking while having open channels presents challenges. Open channels require monitoring the blockchain, and those unaware of the hardfork or late in updating their client could have their funds stolen through old commitment transactions. The risk of retaliation is relatively low for attackers, as others can likely determine the client version. If no replay protection is implemented on the fork, open channels will need to be settled twice. If replay protection is implemented, commitments become invalid on the fork, resulting in financial losses for users.The discussion on Lightning in the context of blockchain hardforks began in an email thread between Christian Decker and Martin Schwarz. They addressed the issue of open channels during a fork, noting that if no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, leading to potential financial losses. To solve this problem, the suggestion was made to redefine chain_id as the hash of the first block of the new branch and require replay and wipe-out protection. The question of whether these requirements can be relaxed and concerns about slow block times were also raised. It was proposed that timestamping of commitments could be integrated into the channel design to address replay protection. It was acknowledged that hardforking with open channels will always be problematic, and those unaware of or late to update their client risk losing their funds.Christian Decker welcomes Martin Schwarz to the Lightning-dev mailing list and agrees with his proposal of using the first forked block as the genesis block for the forkchain to minimize disruption. In cases where channels are open during the fork, a single channel would need to be settled twice. If no replay protection is implemented, the last commitment can be used to close the channel. However, if replay protection is in place, commitments become invalid on the fork, potentially resulting in financial losses. Martin Schwarz raises the question of how Lightning can function across distinct permanent forks of a parent blockchain that share the same genesis block with hardforks branching off the Bitcoin blockchain. He suggests redefining chain_id to the hash of the first block of the new branch and requiring replay and wipe-out protection. The discussion also touches on concerns about slow block times and whether Lightning can transact on "almost frozen" block chains that experience a sudden loss of hash power. Additionally, the participants inquire about previous discussions or studies on Lightning in the context of hardforks. Bryan's contact information is provided at the end of the email thread.
Updated on: 2023-08-01T21:28:01.255982+00:00