user62167: 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?  

user114644: 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?

user60443: 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

62167: <p>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?  </p>
 114644: <p>I am still having problems understanding the relative locktime:</p>
<p>I am aware that the scriptpubkey is &quot;Time Locked&quot; as mentioned above :</p>
<pre><code>   &quot;30d&quot; CHECKSEQUENCEVERIFY DROP
    &lt;Alice's pubkey&gt; CHECKSIG
</code></pre>
<p>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.</p>
<p>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?</p>
 60443: <p>In order to use a relative time lock, you need to provide the requirements in the <code>scriptPubKey</code> to which the Bitcoin is sent.</p>

<h2>Example</h2>

<p><code>scriptPubKey</code> for escrow with 30 day timeout:</p>

<pre><code>IF
    2 &lt;Alice's pubkey&gt; &lt;Bob's pubkey&gt; &lt;Escrow's pubkey&gt; 3 CHECKMULTISIG
ELSE
    "30d" CHECKSEQUENCEVERIFY DROP
    &lt;Alice's pubkey&gt; CHECKSIG
ENDIF
</code></pre>

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

<p><code>scriptSig</code>: <code>0 &lt;signature1&gt; &lt;signature2&gt;</code></p>

<p>Or after 30 days, alice can provide:</p>

<p><code>scriptSig</code>: <code>&lt;signature&gt;</code></p>

<p>See <a href="https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#escrow-with-timeout" rel="nofollow noreferrer">BIP112</a></p>

<h2>Sequence</h2>

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

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

<p>For 30 days, I believe it would be as follows:</p>

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

<p>The sequence is the very last 4 bytes of the transaction, see <a href="https://en.bitcoin.it/wiki/Transaction" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Transaction</a></p>
