Explain lock time / replacing transactions

[jahr]

However we have done a lot of research and documentation on how it can be used:

https://en.bitcoin.it/wiki/Contracts

Sorry for question in old thread,  but it is about the things I'm very interesting too.
So, this functionality is not implemented in bitcoin or any altcoin, am I right?

[1715044291]

1715044291

[1715044291]

1715044291

[1715044291]

1715044291

[Peter Todd]

However we have done a lot of research and documentation on how it can be used:

https://en.bitcoin.it/wiki/Contracts

Sorry for question in old thread,  but it is about the things I'm very interesting too.
So, this functionality is not implemented in bitcoin or any altcoin, am I right?

nLockTime is, mempool transaction replacement isn't.

I added a warning to the contracts page explaining how mempool tx replacement is disabled and that implementors shouldn't assume it ever will be enabled. The page should be rewritten in the future to avoid reference to it.

[jahr]

Thank you for explanation.

[Mike Hearn]

Please don't characterise what "other developers" think so casually. Obviously I think it's viable with some internal resource scheduling work (which is needed anyway), and Satoshi also thought it's viable. Many others haven't even weighed in, as far as I know.

Also, what makes you think it didn't work? I did local transaction replacements on private testnets and it worked fine.

I edited the section to remove the pointless editorialising and simply state the facts as they are.

[jahr]

Also, what makes you think it didn't work? I did local transaction replacements on private testnets and it worked fine.

Would you be so kind to explain in short the simplest method to make transaction replacements for test? Just use createrawtransaction for 2 trxs with different nSequence? Sorry for dumb question,  but I'm completelly new in bitcoin programming and it is very difficult to understand what to do exactly, too many new information.)

[kjj]

From another thread...

Wow, thanks! but that is WAY over my head. I'd better go watch the Khan Academy videos. . .

People will come up with pretty tools to make it easier as we go.  But for now, the guts are certainly here and do work.

This really can be done by hand though, if you have an urgent need to do it.  Decoding a transaction in hex by hand is pretty easy.  Just follow the docs and remember that each byte is 2 chars, and that you are counting in hex (in my example below, the pkscript length 19 is in hex and means 16+9=25).

And double check everything before you send anything.

01000000 - version
01 - vin count
 2084ba9f2f0f98bb - prevout hash
 1cf0320ee1c486b5
 9b6b79e243de7596
 d3e44fa087b597aa
 01000000 - prevout index
 00 - signature script length
 ffffffff - sequence
01 - vout count
 00e1f50500000000 - value
 19 - pkscript length
 76a91428f60d621b - pkscript
 5d07b9c2820c11cc
 c6d41146b53a3e88
 ac
00000000 - locktime

A transaction is final when:
 the sequences are no longer incrementable or
 the locktime is in the past

A transaction that is not final will not be accepted for relay.  The brute force method of transaction replacement, which works with all software on all networks, is to not broadcast the transaction (sendrawtransaction) until it is ready.  Most uses don't actually need any sort of replacement mechanism.

[Mike Hearn]

At the time I just took out the return statement to reactivate that codepath, and then used a bitcoinj app to do the replacement. Nothing fancy.

[MoonShadow]

From another thread...

Wow, thanks! but that is WAY over my head. I'd better go watch the Khan Academy videos. . .

People will come up with pretty tools to make it easier as we go.  But for now, the guts are certainly here and do work.

This really can be done by hand though, if you have an urgent need to do it.  Decoding a transaction in hex by hand is pretty easy.  Just follow the docs and remember that each byte is 2 chars, and that you are counting in hex (in my example below, the pkscript length 19 is in hex and means 16+9=25).

And double check everything before you send anything.

01000000 - version
01 - vin count
 2084ba9f2f0f98bb - prevout hash
 1cf0320ee1c486b5
 9b6b79e243de7596
 d3e44fa087b597aa
 01000000 - prevout index
 00 - signature script length
 ffffffff - sequence
01 - vout count
 00e1f50500000000 - value
 19 - pkscript length
 76a91428f60d621b - pkscript
 5d07b9c2820c11cc
 c6d41146b53a3e88
 ac
00000000 - locktime

A transaction is final when:
 the sequences are no longer incrementable or
 the locktime is in the past

A transaction that is not final will not be accepted for relay.  The brute force method of transaction replacement, which works with all software on all networks, is to not broadcast the transaction (sendrawtransaction) until it is ready.  Most uses don't actually need any sort of replacement mechanism.

This only works for some use cases.  There are a few cases that the transaction must be valid and signed, and broadcasted to at least one third party.  Which still works, because it's not required that said third party distribute further, so long as they are willing to accept that one into their own queue.