3

How does relative timelock work? I mean, I know the theoretical description, but how to use nSequence concretely ? Can you do me a practical example with 2 sample transactions one of which locked with nSequence from another?

5

In order to use a relative time lock, you need to provide the requirements in the scriptPubKey to which the Bitcoin is sent.

Example

scriptPubKey for escrow with 30 day timeout:

IF
    2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
ELSE
    "30d" CHECKSEQUENCEVERIFY DROP
    <Alice's pubkey> CHECKSIG
ENDIF

Then, in order to spend it before 30 days, the scriptSig that satisfies the first conditional statement (multisig script) must be provided, i.e.:

scriptSig: 0 <signature1> <signature2>

Or after 30 days, alice can provide:

scriptSig: <signature>

See BIP112

Sequence

Note that in order to set a relative locktime: the tx must have the following properties:

  • version must be 2 or greater
  • nSequence must not have 32nd bit set
  • nSequence must have the 23rd bit set (0x400000) if it is a lock-time type, unset for block height type
  • for relative lock-time type the granularity of each bit is 512 seconds
  • for relative block height type each bit represents 1 block

For 30 days, I believe it would be as follows:

30 * 24 * 60 * 60 = 2592000 seconds
2592000 / 512 = 5062.5 ~= 5063 or 0x13C7
sequence = 0x13C7 | 0x400000 = 0x4013C7 or 4199367
nSequence = 0xC7134000 (little endian)

The sequence is the very last 4 bytes of the transaction, see https://en.bitcoin.it/wiki/Transaction

8
  • Thank you, very clear. Do u know where to add nSequence parameter inside a transaction? Jan 15 '19 at 8:50
  • 1
    The sequence or locktime is the very last 4 bytes of the transaction, see en.bitcoin.it/wiki/Transaction
    – JBaczuk
    Jan 15 '19 at 12:54
  • @JBaczuk - Has the impact of little endian encoding been taken into consideration after performing BIP 68 bit encoding?
    – skaht
    Jan 15 '19 at 19:24
  • @skaht right, you'd need to convert to little endian before putting it in the transaction
    – JBaczuk
    Jan 15 '19 at 21:19
  • 1
    The nSequence field is not the same as the nLockTime field. The nSequence field is per-input, and inputs can have different values set. See General format (inside a block) of each input of a transaction - Txin in the bitcoin wiki link.
    – arubi
    Jan 16 '19 at 8:54
0

I am still having problems understanding the relative locktime:

I am aware that the scriptpubkey is "Time Locked" as mentioned above :

   "30d" CHECKSEQUENCEVERIFY DROP
    <Alice's pubkey> CHECKSIG

So when I want to spend this output, do I actually have to set the nSequence Field by myself. I mean, what prevents me from just calculating the right values which satisfies the OP_Code. I am missing the actual connection to the real transaction, like which procedure checks that this transaction has really been 30 days in the blockchain since it appeared in a block.

To prevent older nodes from forking of, the final nSequence should also be calculated into a resulting locktime, to prevent older nodes form spending it?

1
  • What's crucial to understand is that the redeem script (the script that you quoted here) that is present must match the script hash in the UTXO. The spender does not control the script. So the spend dictates the value in CSV(value). And CSV(value) WILL fail if value is less than the nSequence in your input which is trying to spend the UTXO (as specified in BIP-068). So BIP-068 sets a way for inputs to be valid only a relative amount of time, while BIP-112 with CSV makes the unlock script writer able to assert a minimum relative amount of time for the input. Oct 29 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.