Published on: 2015-10-19T10:43:05+00:00
On October 16, 2015, Rusty Russell expressed his dissatisfaction with the lack of control over bitcoind's perception of time, making it difficult to conduct blackbox testing. Gavin informed him about the setmocktime function, which Rusty was pleased with.BTC Drak found BIP68 impractical for blackbox testing and suggested a feature request to address this issue. The discussions revolved around the interblock interval in the Bitcoin blockchain and the need for shorter intervals in sidechains like Liquid. Two alternatives were proposed: moving the flag bit indicating use of seconds to bit 23 and reserving bits 17-22 for higher granularity, or putting the units flag in the least significant bit. Adam Back proposed the use of 1-minute blocks if security arguments for limitations on IBLT or fountain codes are found.The email thread also discussed the use of nSequence in BIP68 and proposals for its use in discouraging miners from reorging chains and implementing proof-of-stake blocksize voting. It was decided to use 16 bits for the sequence number in both block and time versions of BIP68, allowing for a resolution of 512 seconds. Rusty Russell proposed changing BIP68 to use 16 bits for the sequence number in both block and time versions. Peter Todd asked for other proposals for implementing this feature via nSequence, and Gregory Maxwell suggested discouraging miners from reorging chains and proof-of-stake blocksize voting.Peter Todd raised concerns about the review process for BIP68 and BIP112, suggesting that the overall design needs to be evaluated as a single unit. Joseph Poon emphasized the need for a relative CLTV and suggested implementing it via nSequence. Mark Friedenbach discussed decreasing granularity as a soft-fork and suggested keeping the highest possible precision. Peter Todd expressed concerns about the implementation of a feature via nSequence and asked for other proposals.The discussion on the bitcoin-dev mailing list revolved around the use of nSequence in BIPs 68, 112, and 113. Peter Todd suggested implementing applications requiring relative CLTV via nSequence. Alex Morcos proposed increasing granularity by reducing the resolution of time-based sequence number locks. The use of RCLTV and OP_CSV in lightning commitment transactions was also discussed. Peter Todd expressed concerns about whether implementing a relative CLTV mechanism using nSequence is the best approach. Anthony Towns discussed the differences between RCLTV and CLTV and suggested that OP_CRLTV alone works fine for BIP68 use cases.Anthony Towns and Peter Todd discussed the implementation of relative CLTV using nSequence in Bitcoin transactions. Todd explained the use of RCLTV/OP_CSV in Lightning commitment transactions and the drawbacks of using absolute CLTV. Peter Todd has requested further work on the rationale for implementing relative lock-time via nSequence in a post to the Bitcoin development mailing list.The purpose of implementing relative lock-time via nSequence is to enforce a delay between publishing the commitment transaction and spending the output in lightning commitment transactions. This delay allows the counterparty to prove that the commitment was revoked and claim the outputs as a penalty. The use of absolute CLTV instead of RCLTV would result in unwanted delays in claiming funds when no cheating is occurring. RCLTV allows for longer availability of a channel, but funds can still be reclaimed quickly in case of problems.While the CHECKSEQUENCEVERIFY (CSV) semantics for BIP68 and BIP112 are mostly ready, implementing relative lock-time without using nSequence may cause a one-year delay for deployment. To avoid this delay, a suggested compromise is to make BIP68 optional by indicating it with a bit in tx nVersion. This would allow for the deployment of relative lock-time without further delays while not permanently limiting future upgrades.BIP112 provides an example called "Escrow with Timeout" which demonstrates the need for relative CLTV. However, there is a lack of clear justification for implementing this feature via nSequence. The proposed new nSequence semantics revolve around a "Consensus-enforced tx replacement" mechanism, using a bidirectional payment channel as an example. However, it is argued that a bidirectional payment channel can be implemented using CLTV alone. The Bitcoin community needs to provide more justifications for this complex soft-fork that limits future upgrades before deploying it. It is crucial to document the semantics and use-cases thoroughly to avoid mistakes similar to the failed feature that led to the creation of nSequence.The CHECKSEQUENCEVERIFY (CSV) semantics, defined by BIP68 and BIP112, introduce a relative CHECKLOCKTIMEVERIFY. 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 utilized for future upgrades. Adding new fields to the serialization format is challenging due to the significant system-wide impact of the required hard-fork.
Updated on: 2023-08-01T16:30:25.033312+00:00