Explain lock time / replacing transactions

[BeeCee1]

The protocol https://en.bitcoin.it/wiki/Protocol_specification includes a lock_time field for transaction (bitcoin doesn't currently implement it), the description from the wiki: "The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired"  Then in TXIn there is a field for sequence, describe as: "Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block."

What is unclear to me is what changes to a transaction would be acceptable in an update, could you change the source coins, the destination address, the script?  And, if they are changed, how would miners determine that this is an updated transaction and not a new, totally different one?

[theymos]

You can change anything if you own all of the inputs. You can even reverse it. Miners can tell because the inputs of the new transaction all have higher sequence numbers than the old ones.

With the non-default SIGHASH modes, multiple people can contribute inputs into a transaction. Then you can only change certain things, depending on the mode.

[JoelKatz]

What is unclear to me is what changes to a transaction would be acceptable in an update, could you change the source coins, the destination address, the script?  And, if they are changed, how would miners determine that this is an updated transaction and not a new, totally different one?

Why would they need to know? If you changed everything in the transaction, what difference does it make whether it's updated or new? And if, say, leave at least one of the coin sources the same, obviously only one transaction can go through anyway.

[BeeCee1]

What is unclear to me is what changes to a transaction would be acceptable in an update, could you change the source coins, the destination address, the script?  And, if they are changed, how would miners determine that this is an updated transaction and not a new, totally different one?

Why would they need to know? If you changed everything in the transaction, what difference does it make whether it's updated or new? And if, say, leave at least one of the coin sources the same, obviously only one transaction can go through anyway.

Lots of questions here.

"Why would they need to know?":  There is a field in the transaction to say it is an updated transaction.  If that is to be useful, you have to know what transaction is being updated.

"If you changed everything in the transaction, what difference does it make whether it's updated or new?" If it is updated then the old transaction wouldn't go through, if it is new then the old transaction  could go through too.  I wouldn't expect people to change everything , even if they changed one of them how would you tell that it is updated?

For example:

You change the output: how do you distinguish it from a double spend attempt.

You change the input(s): how do you distinguish it from a second transaction to the same output?

[TierNolan]

Why would they need to know? If you changed everything in the transaction, what difference does it make whether it's updated or new? And if, say, leave at least one of the coin sources the same, obviously only one transaction can go through anyway.

You want to be able to cancel the previous transaction.  Otherwise, miners wouldn't know which one to include in the block chain.

You lock the transaction so it isn't included in the chain and until that time you can update the transaction.

[genjix]

Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.

So you send out tx A with no fee, and tx B with a fee + lock time.

Two scenarios:

1.  tx A gets included in a block before tx B's locktime finishes. By the time tx B becomes active, tx A is already in a block so it gets dropped.

2. tx A never gets into a block. tx B becomes active + gets into a block. tx A is forgotten.

[TierNolan]

Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.

True, but miners are supposed to prioritise transactions with higher sequence numbers.  If 80% of miners do that, then you have a good chance of the higher one winning.  Also, if you send out the update well in advance, it is even more likely.

[BeeCee1]

Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.

I think I'm beginning to understand this, tell me if I have it right.  A output can only be spent once, thus, if two transactions spend the same output (as one of their inputs) then they count as the same transaction. So if you had two transactions:

T1:
Input1,Input2 -> Output1

T2:
Input1,Input3 -> Output2

They would both be considered different versions of the same transaction since the both share Input1.

If you had a transaction
T3:
Input1 -> Output1 with a lock time that was non-zero and greater than the current block number then that transaction then that transaction is still open, you would be able to broadcast a replacement transaction (with a higher sequence number) and change the output or the script  (or both) to whatever you wanted, but you couldn't change the input.

(I realize this isn't all implemented in the client, I'm just trying to figure out how it will be done when devs get to it.)

[theymos]

You could add additional inputs or remove some of the inputs if there were several. You could even change the input scripts (as long as they still work).

[TierNolan]

Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.

I think I'm beginning to understand this, tell me if I have it right.  A output can only be spent once, thus, if two transactions spend the same output (as one of their inputs) then they count as the same transaction. So if you had two transactions:

T1:
Input1,Input2 -> Output1

T2:
Input1,Input3 -> Output2

They would both be considered different versions of the same transaction since the both share Input1.

I am pretty sure the current client would consider the second transaction that it received invalid, since it is reusing an input.

It would assume that it is a double spend attempt and refuse to forward it to the rest of the network.

If you could get both to miners, then the miner would have to decide which one would be used.

Once one is incorporated into the chain, then the other one is considered dead.

If you had a transaction
T3:
Input1 -> Output1 with a lock time that was non-zero and greater than the current block number then that transaction then that transaction is still open, you would be able to broadcast a replacement transaction (with a higher sequence number) and change the output or the script  (or both) to whatever you wanted, but you couldn't change the input.

That is the intention of the lock system.

[BeeCee1]

You could add additional inputs or remove some of the inputs if there were several. You could even change the input scripts (as long as they still work).

Thanks.  I that clears up a lot.  Can you change the outputs or are they required to be the same?

[theymos]

You can change everything.

[MoonShadow]

Basically if presented with 2 transactions then miners can randomly choose which to include in a block (if using the same outputs). The only condition is that the tx they include mustn't use the same outputs as a tx already in a block.

So you send out tx A with no fee, and tx B with a fee + lock time.

Two scenarios:

1.  tx A gets included in a block before tx B's locktime finishes. By the time tx B becomes active, tx A is already in a block so it gets dropped.

2. tx A never gets into a block. tx B becomes active + gets into a block. tx A is forgotten.

I'm pretty sure that the free transaction that doesn't consider a lock time would render the one with the fee and lock time invalid.  The reason for this is because the scripting system is required to use a lock time, and this requires a fee, but it's the use of the lock time that keeps the inputs from being 'commited' by the clients that see the lock time transaction.  However, the regular (feeless) transaction would cause the inputs to be 'commited' by the clients, and thus the scripted transaction would become invalid and be dropped before it's lock expired.  I could be wrong about this, not sure.

[Pieter Wuille]

You can change everything.

This is not true. All prevouts must remain identical and none may be removed or added, for a transaction to be considered a new version of another. Input scripts may be changed, though.

For outputs, you can change everything.

[molecular]

You can change everything.

This is not true. All prevouts must remain identical and none may be removed or added, for a transaction to be considered a new version of another. Input scripts may be changed, though.

For outputs, you can change everything.

sorry to necro this thread.

I like this feature. Is it implemented by now and if so what are the implications of "old clients" being around that don't yet implement this?

[Mike Hearn]

Transaction replacement has been "implemented" since day 1, but it was switched off until some concerns with it can be addressed.

Those concerns were not yet addressed so it wasn't yet switched back on.

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

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

[MatthewLM]

If locktime is disabled, what is this? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2058

[Pieter Wuille]

If locktime is disabled, what is this? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2058

nLockTime is implemented and has always been enabled (disabling this would be a forking change).

It is transaction replacement (which is related, but not the same thing) which is disabled (and enabling this is just a local implementation change, not a forking change).

[smithd98@gmail.com]

Transaction replacement has been "implemented" since day 1, but it was switched off until some concerns with it can be addressed.

Those concerns were not yet addressed so it wasn't yet switched back on.

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

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

Mike thanks for the link! Those features are exciting!

[Meccup]

You lock the transaction so it isn't included in the chain and until that time you can update the transaction.

Vice versa... You unlock transaction for further changes...