Bitcoin Forum
December 11, 2016, 06:21:38 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Explain lock time / replacing transactions  (Read 7646 times)
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
June 28, 2011, 02:32:43 AM
 #1

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481437298
Hero Member
*
Offline Offline

Posts: 1481437298

View Profile Personal Message (Offline)

Ignore
1481437298
Reply with quote  #2

1481437298
Report to moderator
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
June 28, 2011, 02:58:46 AM
 #2

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 03:08:58 AM
 #3

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.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
June 28, 2011, 11:18:42 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1050


View Profile
June 28, 2011, 11:37:25 PM
 #5

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
June 29, 2011, 12:54:23 AM
 #6

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
*
Offline Offline

Activity: 1050


View Profile
June 29, 2011, 01:16:57 AM
 #7

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
June 29, 2011, 02:45:21 AM
 #8

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
June 29, 2011, 03:18:15 AM
 #9

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
TierNolan
Legendary
*
Offline Offline

Activity: 1050


View Profile
June 29, 2011, 09:30:34 AM
 #10

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.

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

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
BeeCee1
Member
**
Offline Offline

Activity: 116


View Profile
June 30, 2011, 01:30:32 AM
 #11

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
June 30, 2011, 02:10:27 AM
 #12

You can change everything.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
June 30, 2011, 02:16:35 AM
 #13

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
June 30, 2011, 07:28:24 AM
 #14

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
molecular
Donator
Legendary
*
Offline Offline

Activity: 2142



View Profile
December 07, 2012, 07:35:31 AM
 #15

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?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
December 07, 2012, 11:11:29 AM
 #16

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
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
December 07, 2012, 01:32:29 PM
 #17

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

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
December 07, 2012, 01:38:17 PM
 #18


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

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
smithd98@gmail.com
Newbie
*
Offline Offline

Activity: 26


View Profile WWW
August 18, 2013, 03:06:55 PM
 #19

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
Newbie
*
Offline Offline

Activity: 15

Meccup


View Profile
January 12, 2014, 01:13:45 AM
 #20

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...
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!