Author: Spartacus Rex 2017-11-13 17:02:07
Published on: 2017-11-13T17:02:07+00:00
The discussion is around a replay protection scheme for Bitcoin, specifically for Lightning Network (LN) transactions. One suggestion is to put the hash of a block that must be on the chain the transaction can eventually be added to. This allows users to choose which forks they want to allow their transaction on, pre-fork for both or post-fork for only one, without requiring an `nForkId` value. However, there are concerns about this method missing some cases due to forks forming a partial order while IDs form a total order. The discussion also touches on the nForkId values for LN transactions, where the funding transaction needs to be protected by setting `nForkId>=1`, while the commitment transaction should have `nForkId=0`. This ensures that the payment channel is non-existent on any past forks and valid on all chains for future forks, but the parent transaction it tries to spend (the funding transaction) exists only on two chains - the original one and the one that forked away. There are potential pitfalls with using nForkId 0 for LN transactions, as it could be valid not just for future forks, but also on past ones.
Updated on: 2023-06-12T22:02:29.775826+00:00