Bitcoin Forum

The protocol https://en.bitcoin.it/wiki/Protocol_specification (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?

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.

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?

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.

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.

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.

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.)

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).

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.


That is the intention of the lock system.

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

You can change everything.

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.

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?

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

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).

Mike thanks for the link! Those features are exciting!

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

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 (https://en.bitcoin.it/wiki/Contracts#A_warning_about_the_mempool_transaction_replacement_mechanism) 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.

Thank you for explanation.

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.

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.)

From another thread...


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.

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.

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.