Topic: Inverse of nlocktime -- OP_CHECKLOCKTIMEVERIFY related question (Read 954 times)

Yeah.  The worst part about it is that Bob is the one who decides when the nLastTime transaction goes onto the network, so he can very deliberately aim for the very last block it can get into, do an immediate spend to some merchant who accepts zero-confirmation transactions, and some fraction of the time, without Bob even needing any mining power, it'll happen to be an orphan block. 

So, yes, nLastTime definitely needs OP_CHECKLOCKTIMEVERIFY to be anything reasonable. 

That makes sense. So OP_CHECKLOCKTIMEVERIFY could be used to make nLastTime safe once it's implememted. One step at a time I suppose. Thanks, Cryddit, for such a concise and helpful response.

No. 

BIP65's OP_CHECKLOCKTIMEVERIFY is about a script instruction to create a transaction whose outputs are unspendable until some particular block (or time).  nLockTime is a transaction that cannot be put into the block chain in the first place until some particular block (or time).  Both of these are of the "not yet" variety rather than the "not any more" variety.

You are looking for nLastTime, which I have been assured will never be accepted into Bitcoin core because people don't want to deal with legitimate transactions (ie, not depending on a deliberate double spend) becoming undone in the event of a reorg. 

The issue is that if Alice pays Bob with a transaction with an nLastTime set for block n, and Bob gets into into block n-1 and immediately spends the output to Carol and David, and then there's a reorg back to block n-1 - except this time Alice's transaction to Bob doesn't get into block n-1, because the miner in the reorg didn't pick it up.  Alice and Bob know what's going on, because they made that transaction and the nLastTime was their choice.  But Carol and David have done nothing wrong, and their money from Bob just disappeared.  They had valid transactions, those transactions haven't changed at all, and they can't get into the new block chain.  The effect against them is the same as though Bob had gotten away with a double spend.  Bob is out nothing, because the payment he wound up not making to Carol and David is the same money he didn't get from Alice.  Alice is looking at an nLastTime order that Bob didn't exercise before time ran out, so she doesn't see anything wrong.  But Carol and David got screwed over, especially if Bob now has merchandise from them.

It occurs to me that with an OP_CHECKLOCKTIMEVERIFY to make sure that nobody spends the output of an nLastTime transaction until it's at least a dozen blocks deep in the block chain, much of the problem with nLastTime goes away.  So maybe you can consider OP_CHECKLOCKTIMEVERIFY as something that isn't yet what you want, but makes it possible to add what you want without causing horrible problems.

I've been reading a little about BIP65 regarding OP_CHECKLOCKTIMEVERIFY and had a question.  With this new scripting will there be (or could there be) a way to specify a block height after which a transaction can no longer be included in the blockchain?  This would effectively be the inverse of nlocktime and put an expiration on a transaction, which would be useful for smart contracts and payment channels.