Bitcoin Forum
December 10, 2016, 03:05:24 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: When are transactions final (in case of a time lock) ?  (Read 1730 times)
Forp
Full Member
***
Offline Offline

Activity: 198


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.
1481382324
Hero Member
*
Offline Offline

Posts: 1481382324

View Profile Personal Message (Offline)

Ignore
1481382324
Reply with quote  #2

1481382324
Report to moderator
1481382324
Hero Member
*
Offline Offline

Posts: 1481382324

View Profile Personal Message (Offline)

Ignore
1481382324
Reply with quote  #2

1481382324
Report to moderator
Creating a Bitcoin client that fully implements the network protocol is extremely difficult. Bitcoin-Qt is the only known safe implementation of a full node. Some other projects attempt to compete, but it is not recommended to use such software for anything serious. (Lightweight clients like Electrum and MultiBit are OK.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481382324
Hero Member
*
Offline Offline

Posts: 1481382324

View Profile Personal Message (Offline)

Ignore
1481382324
Reply with quote  #2

1481382324
Report to moderator
1481382324
Hero Member
*
Offline Offline

Posts: 1481382324

View Profile Personal Message (Offline)

Ignore
1481382324
Reply with quote  #2

1481382324
Report to moderator
1481382324
Hero Member
*
Offline Offline

Posts: 1481382324

View Profile Personal Message (Offline)

Ignore
1481382324
Reply with quote  #2

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

Activity: 327



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.

titeuf_87
Member
**
Offline Offline

Activity: 112


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:  

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!