Published on: 2015-11-24T05:58:40+00:00
In a discussion on the bitcoin-dev mailing list, Peter Todd proposed changes to BIP68, which defines the rules for locktime in transactions. The current specification creates an awkward situation where users of by-height locktimes have 14 bits unused in nSequence, but by-time locktimes only have 5 bits unused. Todd suggests making by-time locks use the same number of bits as by-height locks, and multiplying the by-time lock field by the block interval.Another participant in the discussion pointed out that this issue had already been addressed and resolved in a previous version of the specification. Todd was pleased to see that his conclusions matched those of previous discussions.BIP68 is a representation of lock-time values, allowing for transactions to be locked for a specific period or until a certain block height. By-height locks are represented as a 16-bit integer while by-time locks are represented as a 25-bit integer with a granularity of 1 second. However, this granularity does not align with BIP113, which uses the median time-past as the endpoint for lock-time calculations and may pose problems for future upgrades.There are two cases to consider when using lock-time values: no competing transactions and competing transactions. In the former case, exact miner behavior is irrelevant and granularity below an hour or two has little significance. In the latter case, miners are expected to prefer lower sequence numbers, allowing for bidirectional payment channels to decrement nSequence for each change of direction. BIP113 calculates the median time-past by taking the median time of the previous 11 blocks, meaning miners have no control over it.This renders granularity below a block interval ineffective in determining which transaction the miner includes. Therefore, users will want to use significantly larger than 1 block interval granularity in protocols.The downside of BIP68 is that unused bits in nSequence present an awkward situation if new meanings need to be added and more than five bits are required. The recommendation is to modify BIP68 to make by-time locks have the same number of bits as by-height locks and multiply the by-time lock field by the block interval. By aligning the number of bits and incorporating the block interval, this modification can address the issue of unused bits and ensure a more efficient representation of locktime values.Overall, the discussion on bitcoin-dev mailing list highlights the need for improvements in the BIP68 specification regarding the representation of locktime values. Peter Todd's proposed changes aim to address the issue of unused bits and provide a more consistent and effective approach. The previous resolution mentioned by another participant reflects the ongoing efforts to enhance the specification based on collective discussions and insights from various contributors.
Updated on: 2023-08-01T16:54:09.594754+00:00