Author: ZmnSCPxj 2020-01-12 15:01:06
Published on: 2020-01-12T15:01:06+00:00
The email thread discusses the use of `nSequence` relative-locktime transactions in unilateral closes and the issue of obsolete `nLockTime`. The solution proposed is to sign multiple versions of a commitment transaction with different `nLockTimes`, but there must exist a limit on the largest-`nLockTime` commitment transaction. If the largest-`nLockTime` commitment transaction is approaching and the counterparty goes offline, it creates a Morton fork. Bitcoin Core's solution would be to toss a coin and choose between non-relative-locktime `nSequence` and an `nLockTime` of the next block or relative-locktime `nSequence` equal to the confirmations of the output being spent and an `nLockTime` of 0. However, there is a significant bias that can be used to identify LN transactions for analytics or censorship. Assuming both counterparties have a balance on the channel, at least one output must be spendable with a relative lock time. One output will be directly spendable by the remote side, and one output will be spendable by the local side after a relative locktime from the commitment transaction.
Updated on: 2023-06-02T22:17:37.597089+00:00