Author: jl2012 at xbt.hk 2015-10-03 18:49:20
Published on: 2015-10-03T18:49:20+00:00
The CHECKSEQUENCEVERIFY semantics for BIP68 and BIP112 are mostly ready, however, implementing relative-locktime without using nSequence may cause a delay of another year for deployment. To avoid this delay, a suggested compromise is to make BIP68 optional, indicated by a bit in tx nVersion. This will allow deploying relative-locktime without further delay while not permanently limiting future upgrades. BIP112 provides the example "Escrow with Timeout", which is an application that requires a relative (instead of absolute CLTV), along with other use cases described in the CLTV BIP. However, it has not been clearly shown why implementing this feature via nSequence is necessary. The rational behind the new nSequence semantics is a "Consensus-enforced tx replacement" mechanism, with a bidirectional payment channel as an example. However, the bidirectional payment channel concept can be implemented with CLTV alone. The Bitcoin community needs to come up with more justifications for the fairly complex soft-fork that limits future upgrades before deploying it. Semantics and use-cases need to be documented before deployment to avoid making mistakes like the failed feature that led to the creation of nSequence.
Updated on: 2023-06-10T23:46:03.672541+00:00