Explain lock time / replacing transactions - page 2.

BeeCee1

member

Activity: 115

Merit: 10

Quote from: genjix on June 28, 2011, 07:54:23 PM

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

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: genjix on June 28, 2011, 07:54:23 PM

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.

genjix

legendary

Activity: 1232

Merit: 1076

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

legendary

Activity: 1232

Merit: 1094

Quote from: JoelKatz on June 27, 2011, 10:08:58 PM

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.

BeeCee1

member

Activity: 115

Merit: 10

Quote from: JoelKatz on June 27, 2011, 10:08:58 PM

Quote from: BeeCee1 on June 27, 2011, 09:32:43 PM

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?

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Quote from: BeeCee1 on June 27, 2011, 09:32:43 PM

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.

theymos

administrator

Activity: 5222

Merit: 13032

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.

BeeCee1

member

Activity: 115

Merit: 10

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?

Topic: Explain lock time / replacing transactions - page 2. (Read 9207 times)