1
BIP 68 redefines the input sequence number field as bit vector that encodes a relative lock time.
A transaction can be encumbered with an absolute lock time by setting the nLockTime field to a non-zero value and by ensuring that at least one input sequence is non-maximal (not 0xffffffff).
What happens if a one-input transaction sets nLockTime > 0 and introduces a relative lock time under BIP 68? For example, nLockTime might expire in 12,000 blocks and the input's relative lock time might expire in 11,000 blocks. Conversely, the relative lock time might expire after the absolute lock time.
Which locking mechanism wins in these cases? Are both locks checked, or only one? If the latter, which one?
The "Compatibility" section of BIP 68 hints that both locks will be checked, but from my reading doesn't state this explicitly:
The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
So both time locks will be evaluated, no? Neither will override the other, in other words. If so, can you point to a source (other than the paragraph in BIP 68 I quoted)? – Rich Apodaca – 2016-07-13T15:11:10.183
1It depends on the
nsequencefield. If the disable flag is set, then it will not be evaluated (as there will be no consensus meaning). Otherwise, it will be evaluated. You can inspect this in the Bitcoin Core source code, script/interpretter.cpp line 334 onwards. The behavior of OP_CSV and Timelocks are different, they never override each other as they semantically mean different things. – renlord – 2016-07-13T23:07:48.320