Author: Jacob Eliosoff 2017-11-13 15:31:55
Published on: 2017-11-13T15:31:55+00:00
The conversation discusses the implementation of replay protection in Bitcoin forks. The user asks how a transaction can specify a constraint like "nForkId>=1", to which Mats Jerratsch explains that it is set on the funding transaction to protect it from replay-attacks on past forks. However, if another fork happens during the lifetime of the payment channel, the payment exists for both tokens. To address this issue, the commitment transaction has an nForkId=0, making it valid on both chains. The parent transaction it tries to spend (the funding transaction) only exists on two chains, the original and the one that forked away. The conversation also touches upon the potential pitfalls of using nForkId 0, as users would have to be aware that these transactions are valid not only on future forks but also on past ones, which may cause confusion.
Updated on: 2023-06-12T22:02:18.579231+00:00