[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime



Summary:

Mark Friedenbach, a developer for bitcoin-dev, created two new repositories with changed rules regarding sequence numbers. The first repository, sequencenumbers2, inverts the sequence number and interprets nSequence=1 as one block relative lock-height, and nSequence=LOCKTIME_THRESHOLD as one second relative lock-height. Additionally, nSequence>=0x80000000 (most significant bit set) is not interpreted as a relative lock-time. The second repository, sequencenumbers3, not only inverts the sequence number but also interprets it as a fixed-point number. This allows up to five-year relative lock times using blocks as units and saves 12 low-order bits for future use. Or, up to approximately two-year relative lock times using seconds as units and saves four bits for future use without second-level granularity. According to Friedenbach's calculations, time-based relative lock time requires about 19 bits, and block-based relative lock-time requires about 18 bits, leaving 13 or 14 bits for other uses. However, Friedenbach is unsure of what an appropriate maximum to choose is. He has considered use cases that have only had lock times on the order of a few days to a month or so. While he would feel uncomfortable going less than a year for a hard maximum, he is having trouble thinking of any use case that would require more than a year of lock-time. Jorge Timón suggested representing one block with more than one increment, which would leave additional space for future signaling, or allow higher resolution numbers for a sharechain commitment. However, this suggestion was not previously considered.


Updated on: 2023-06-10T19:21:56.105435+00:00