Bitcoin Forum
May 14, 2024, 12:12:29 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: When are transactions final (in case of a time lock) ?  (Read 1924 times)
Forp (OP)
Full Member
***
Offline Offline

Activity: 195
Merit: 100


View Profile
June 18, 2011, 02:16:01 PM
 #1

main.h: CTransaction::IsFinal() decides, when a transaction is considered final.  Smiley

Now, it looks like nLockTime is not really used currently, so if is the line

if (nLockTime == 0) return true;

which usually is doing its job here.  Smiley

A bit lower in the code there is this little thingie:  Huh

if ((int64)nLockTime < (nLockTime < 500000000 ? (int64)nBlockHeight : nBlockTime))  return true;

which I personally would have expected to be  Undecided

   if ((int64)nLockTime < nBlockTime)  return true;

What is the purpose of comparing to BlockHeight in case nLockTime is smaller than 500 000 000. 500 000 000 is definitely in the past?  Huh Huh Huh

As nLockTime is compared to GetAdjustedTime() earlier in the code, it is absolute Unix epoch time. 500 000 000 is November 05, 1985, 01:53:20 in my timezone. What's the idea of comparing with this date in the past ?!? Moreover: if nLockTime < 500000000 then almost certainly also nLockTime < nBlockHeight so this earlier test does not make sense ?!?

I would appreciate any ideas shedding some light on this line of code.

And, while being in this part of the code, a bit lower in IsFinal() we find:

   BOOST_FOREACH(const CTxIn& txin, vin) if (!txin.IsFinal()) return false;

The logic is obvious: If an input to a transaction is not final, then the transaction under consideration is not final. But...hm...shouldn't this be the very first thing to check? There are various cases earlier in the function which lets the system decide that a transaction is final - without having made this check.
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
1715645549
Hero Member
*
Offline Offline

Posts: 1715645549

View Profile Personal Message (Offline)

Ignore
1715645549
Reply with quote  #2

1715645549
Report to moderator
riX
Sr. Member
****
Offline Offline

Activity: 326
Merit: 252



View Profile
June 18, 2011, 03:28:41 PM
 #2

I don't understand it either. Maybe 500000000 is just some number inserted to show possible functionality for nLockTime, or maybe for returning the same result as 0 when people thinks nLockTime is a block number instead of a unix timestamp.

Sorry, I can't help you with your lost password.

PGP key: 0x9F31802C79642F25
titeuf_87
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
June 18, 2011, 09:13:42 PM
 #3

This locktime stored in every transaction can be used for two different purposes, 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 (replacement is currently disabled in Bitcoin, however, so this is useless). "

This is the reason why this 500 000 000 is in the condition: if nLockTime is smaller than that, it is assumed to be a block number, otherwise it's assumed to be a timestamp.

If this is not the case and nLockTime is for a time in the future for example, every input from that transaction will be checked, which does this:
Code:
bool IsFinal() const
{
    return (nSequence == UINT_MAX);
}

If the sequence number of every input is equal to UINT_MAX then this transaction is considered final, even though the nLockTime refers to a future block/time.

The reason why this is done is because as long as nLockTime refers to the future, the creator of this transaction can make new versions of it. This is done by increasing the sequence number of the input. If every input has UINT_MAX as sequence number, no new versions of it can be created anymore as otherwise it would result in an overflow.

I hope this helps. I can't guarantee how correct this is, but this is just what I read from both the wiki and the code Smiley

15kfBM3TQ4PGzL7cKncU3su2pH7ZJmiLtr
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!