Author: Jacob Eliosoff 2017-11-15 05:02:48
Published on: 2017-11-15T05:02:48+00:00
The discussion in this email thread revolves around a proposal for creating fork-specific addresses to make transactions safer and allow light clients to differentiate between multiple forks. The proposal suggests assigning a unique 'nForkId' to every leaf, which needs to match the 'nForkId' of the software validating it to be considered valid. The proposal faces a dilemma where an LN commitment transaction either has to be given the specific 'nForkId' of the fork it's created on or be given 'nForkId 0,' which has a flaw. To avoid this dilemma, it may make sense to incorporate Luke's OP_CHECKBLOCKATHEIGHT and make the fork ID a (block height, hash) pair rather than just a number. Additionally, using solutions like SIGHASH_BLOCKCOMMIT could be superior in making transactions difficult to circumvent. However, the proposed solution not only adds replay protection but also makes transacting safer overall due to a dedicated address format per fork and helps avoid issues like sending BCH to a BTC address. Every leaf must be assigned a unique 'nForkId,' and transactions are only valid if their 'nForkId' matches exactly the 'nForkId' of the software validating them.
Updated on: 2023-06-12T22:02:41.867195+00:00