CHECKSEQUENCEVERIFY - We need more usecases to motivate the change



Summary:

The CHECKSEQUENCEVERIFY (CSV) semantics are defined by BIP68 and BIP112, which can be summarized as a relative CHECKLOCKTIMEVERIFY. However, CSV defines the behavior for the previously undefined nSequence field, which is the only free-form field in the transaction serialization format that can be used for future upgrades. Adding new fields to the serialization format is difficult due to the broad system-wide impact of the hard-fork required to do so. Therefore, it is important to justify the new behavior carefully as it limits options in the future.Two main things need to be justified: the need for a relative CLTV and the implementation of this via nSequence. The example "Escrow with Timeout" provided in BIP112 justifies the need for relative CLTV. However, more examples would be useful. On the other hand, the rational for the nSequence semantics as described in BIP68, a "consensus-enforced tx replacement" mechanism, does not provide enough justification for a complex soft-fork that limits future upgrades. More justification is needed before deployment, especially since nSequence itself exists because of a failed feature that did not work as intended.


Updated on: 2023-06-10T23:47:04.766025+00:00