thanks for the reply I seem to have gotten it working and also found a bip68 lib for bitcoinjs as well

Hi

I have a question about BIP112 and BIP68 (I am using bitcoin-js lib to implement)

I locked up an output using csv and set the lock time to decimal 169, if I understand correctly this should be around 1 day (as 512 * 169 is the num of seconds in a day roughly)

bitcoin.script.number.encode(169),
bitcoin.opcodes.OP_NOP3,
bitcoin.opcodes.OP_DROP

I understand in the tx that spends the utxo I need to set the nSequence number according to bip68

Here I get a little confused, but I created the following decimal number 4194473 to set the nSequence based on the following logic

create a string to represent the 32 byte sequence and set the disable flag to 0 and the version flag to 1 (to interpret as time and not blocks)
0xxxxxxxx1xxxxxx

convert the lock number of 169 into binary
10101001

pad some zeros at the end to make it 16 bits long
0000000010101001

append it to the end of the first binary number with disable and version flag
00000000010000000000000010101001

convert to decimal so I can set the number easily in bitcoin-js
input["sequence"]=4194473

I guess I will find out if I can redeem in a day but is this the correct understanding of BIP 112 and BIP 68?

Thanks

Just to help anybody who may be having a similar issue I think I found the answer to my question

So there are two transactions in question, the first is the P2SH transaction containing the OP_CSV and the second is the spending transaction

In the first transaction if you set an input script to 10 OP_CSV you are saying that you want the second spending transaction that uses this input (or output at this point) as a utxo to have an nSequence number the same or greater.

In other words the stack will validate if your spending transactions inputs nSequence number is not less than the value (10 in this case) placed in the locking script

Reference is here
https://bitcoin.stackexchange.com/questions/45806/op-checksequenceverify-why-to-put-it-into-nsequence-field-if-it-is-already-into

Furthermore the number (10 in this case) can be interpreted as number of blocks or as an actual timespan in seconds according to BIP68 https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

To me it seems to think of the nSequence number not as a single decimal number but as a list of bits, certain bits in this list of bits are used to represent the number you want to lock the time to, and other certain bits in this list of bits are more like switches that you turn on or off to change the interpretation of the number to number of blocks or timespan in seconds

specifically if you think of your nSequence number as this binary number, the zeros towards the end can be set to represent the value, the 0 towards the middle can be set to change the interpretation and the zero at the end can be set to enable or disable any interpretation at all

0xxxxxxxx0xxxxxx0000000000000000

again more detail is in the official BIP68

anyway i'm sure I made some inaccuracies but thats my understanding so far

SOLVED: Seems I was spending the output of the previous tx

I created an RBF transaction and bumped the fee, it was broadcast, no I am trying to bump the fee again a 2nd time however I get a "missing inputs error"

Am I doing something wrong?

here is the tx I want to bump a 2nd time https://blockchain.info/tx/f04244bb95413babb590f37c6971b15be68b827b56fd504ea0fe8c30f93ce9c0

here is the signed tx 01000000042a9266ae15dddb7045ea7d76ee13c5488bda31a5937a869148273c0c9cf2be9e01000 0006b483045022100a1175d155fbc6bbe8544d8b2ed660317d9ef5063bffe9718e679bf4c16ec58 aa02202ac51658902beceda4ba2bb9112edd9a8267c20acaacf01326c663fd4f37b6cd012102eec bf9551f08fd1518408d7ea5a0234d834e97393cf549fb9089b3d53c1a0c26fdffffffc0e93cf930 8cfea04e50fd567b828be65bb171697cf390b5ab3b4195bb4442f0010000006b483045022100a32 cda0ec787ae3431b5f910e25e3cb5931980f8b756a0515e53fd30a0d15a3602204323b72fa2e4f6 3a92514bae978303d1e270bcedd496f8f16230ed7a1d7154ae012102eecbf9551f08fd1518408d7 ea5a0234d834e97393cf549fb9089b3d53c1a0c26fdffffff04f09e4d83513188f7b2b0e69210f0 9bbfa53c72495b2b0151ce1638036e3505010000006a47304402204ee730cc63ab040759d3bf958 0014e37f94eeb9961cc1cb641f3dc211e0b2a3c02206b16a932fd757c2726a0b6a8d8c434c6351b 5d041304603b28f636155e9cdfec012102eecbf9551f08fd1518408d7ea5a0234d834e97393cf54 9fb9089b3d53c1a0c26fdffffff259eccdc3cdc0ee43826b18d5c9563d5b7e19139cc14f2c687f3 537bf55daf8d000000006a473044022064d7c6df21050b0575b0728c6f4da636b8092ed0d27f95f a740275e3f68e619f02203068782b7f009885a4ea9548461cbb9ae63691ac04bd8708e13da23b9d 52cba7012102eecbf9551f08fd1518408d7ea5a0234d834e97393cf549fb9089b3d53c1a0c26fdf fffff020000000000000000356a33d9ae586e98f01f027a7f313f833dc027d0c1f89234d7dfdf75 20e431bfb9e33d748bc113ec156af62fbfc3fe59f28fef1e9b720f100000000000001976a914ede e861dff4de166683e4c54ae3869cd05c7ae0f88ac00000000

thanks

I believe it was via btc or btc.com, anyway I can imagine a miner rejecting rbf transactions for political reasons

Thanks, it was a hypothetical question I had as bitcoin core is backwards compatible with older versions so I assumed there may still be some nodes that do not accept RBF, having said that I doubt they are mining

I have a question, say I broadcast a transaction with an RBF flag, and then try to replace it with a new version at a higher fee.
Is there not a case in which some nodes that don't support RBF reject it as they see it as double spent.
Now you have some nodes that still contain the original transaction ignoring the new one and is there not a chance that it could still get minded?
Thanks

Hi
I read about CSV and got totally confused by the who flag, nsequence number part of it

so if you could help me on a few points id be much obliged!

Say I want a utxo to be spendable after say 10 blocks
so my script would be as so? OP_10 OPCSV OP_DROP

1.)what do I set nSequence to on the input?
2.) I have to worry about setting the nSequence value on the spend transaction inputs correct?

Any sample code that anybody has would be helpful to see if anybody has it

Thanks