How does BIP0068 work?

[Ilsk]

I am trying to create a transaction with relative lock time using BIP 68, but I have some problem setting the sequence number correctly.

I tried to leave the bit (1<<31) not set to have the sequence number interpreted as relative lock time, the bit (1<<22) not set so the relative lock-time specifies a number of blocks and not a timespan, and then since the BIP only interprets 16 bits of the sequence number as relative lock-time, I applied the mask 0x0000ffff to the sequence field, trying to set some very large number such as 0x0000afff.

I did some tests on both testnet and mainnet and every time the transaction was immediately recognised as valid, instead of remaining invalid until the number of blocks specified in the nsequence were passed.

Is there someone who can explain me what did I do wrong, or have an example of a correctly set relative lock time?

NB: At the moment I am not interested in the CSV, I'm just trying to understand how the relative lock time specified in BIP68 works.

[1715220412]

1715220412

[1715220412]

1715220412

[1715220412]

1715220412

[1715220412]

1715220412

[1715220412]

1715220412

[1715220412]

1715220412

[MattWin]

I'm interested as well. Does anybody on this forum know?

[achow101]

Were your transactions Version 2 transactions?

[Ilsk]

Were your transactions Version 2 transactions?

That was exactly my mistake, even if the BIP clearly says to do so I didn't noticed it. Now I tried a test transaction and the client gave me the following error when the sequence number was too high:

Code:

64: non-BIP68-final (code -26) 

Then I decreased the sequence number and the transaction has been correctly broadcasted.

Thank you so much for you help, much appreciated, I spent a lot of time trying to figure out what I was doing wrong

[cygan]

how bip68 works and how the relative lock-time using nsequence actually looks like can be seen very well in the 4 following slides