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



Summary:

The email conversation discusses the nVersion and nSequence fields in a Bitcoin transaction. The author suggests spending a bit in tx nVersion to indicate the activation of BIP68 instead of permanently changing the meaning of nSequence. BIP68 is already optional by toggling the most significant bit, but the author believes that moving the flag from nSequence to nVersion would leave much bigger room for using nSequence for other purposes in the future. They note that nSequence is the only user definable and signed element in TxIn, and suggest that if nSequence had 8 bytes instead of 4 bytes, it could be used to indicate the value of the input. The discussion also touches on the idea of 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.


Updated on: 2023-06-10T19:22:25.534571+00:00