From: Rusty Russell <rusty@rustcorp.com.au>
To: Mark Friedenbach <mark@friedenbach.org>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Thu, 02 Jul 2015 12:08:58 +0930
Message-ID: <873817s2pp.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP 68 Questions
Precedence: list

Hi Mark,

        It looks like the code in BIP 68 compares the input's nSequence
against the transaction's nLockTime:

        if ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD)
            nMinHeight = std::max(nMinHeight, (int)tx.nLockTime);
        else
            nMinTime = std::max(nMinTime, (int64_t)tx.nLockTime);
    
        if (nMinHeight >= nBlockHeight)
            return nMinHeight;
        if (nMinTime >= nBlockTime)
            return nMinTime;
            
So if transaction B spends the output of transaction A:

1.  If A is in the blockchain already, you don't need a relative
    locktime since you know A's time.
2.  If it isn't, you can't create B since you don't know what
    value to set nLockTime to.

How was this supposed to work?

Thanks,
Rusty.