Topic: Peter Todd's OP_CHECKLOCKTIMEVERIFY (Read 3020 times)

https://www.cryptocoinsnews.com/checklocktimeverify-means-bitcoin-escrow-refunds-fork/


bitcoin price to da moon !!! 

what's the TDLR on this - why does it matter?

The effect on compact proofs of misbehavior immediately comes to mind if done badly.


Well, my thinking re: Viacoin is it wouldn't be a crazy idea to use the young age of the coin to hard-fork in less strict time checking, say a 4 hour window to be sure that daylight savings changes don't cause problems. Not a big deal, but it sends the right message.


Right, I'll look into that.

Anyway, for OP_CHECKLOCKTIMEVERIFY specifically seems that the following form would make sense:

    OP_0 OP_CHECKLOCKTIMEVERIFY

If in the future it's decided that you really need different behavior - say for testing time and block nLockTimes in the same transaction - the OP_0 can be changed to something else to soft-fork in new behavior with the same opcode. Otherwise anything but OP_0 behaves as a NOP.

Basically just a specific instance of the "OP_EXTENSION" pattern to enable as many new opcodes as you could ever want that I mentioned before on the mailing list.

Including things which are not a function of the transaction changes the model pretty substantially though. There isn't too much that comes to mind as "would also break" but it seems like the sort of thing that may have subtle implications.

Perhaps, but there really isn't a reason that the network couldn't soft fork in more strict time checking such that similar shenanigans would only really work if a supermajority of hashpower was in on it.  An argument against it is that people will use centeralized sources of time if you ask them for second level precision, but thats not fundamental.

I do somewhat wish the nlocktime time check were on the median of 11, which would make the funny business much less attractive— actually that could be a soft-forking change, since the median is strictly less than the block time.  Basically in that case lying about your time wouldn't help you specifically mine a transaction.

Well one way to think about all this is that a script is valid in a given context. Currently that context is simply the transaction itself and the scriptPubKeys of previous transactions; my patch would expand that context to include the transaction and the current block height/time. Your version of the patch cleverly avoids having to expand the context.

We've already got good reason to expand the context to be at least the CTxOut's of previous transactions, and expanding it still further to include things like block hashes is a common request. If more such things were added I'd be inclined to formalize this notion of "Context" in the EvalScript() and so-on routines. Easy to see why you might not want to have to do that of course.

Pity Satoshi just didn't make transactions have a nLockHeight and nLockTime separately.


Well as we discussed before on -wizards, locktime usage with a timelock rather than a block height lock may create bad incentives for miners to skew timestamps anyway; might be a good idea to disable it entirely. Also, it's not the 2038 problem, it's later: nLockTime is unsigned.


Well, they're both ideas at this point, not fully fledged "implementations" per-se. I'm sure quite sure what's the better approach; need to think through it all some more.

Thanks very much for making the patch source available!

I try to get my head around about your conversation with Peter regarding to the implementation details, but I am not sure what is the better implementation Peter's or yours?

It is understandable that the roll out of new features for an existing and widely used system is not always a straight forward task, but still, it would be great to see new and useful features like your work to be integrated to Bitcoin.
The consensus process is an interesting aspect of the Bitcoin project, even news articles speculate all the time about this process and the politics involved with it. I have no idea what's happening behind the closed doors, but the speculations in the news are interesting reading 

Is the source of your new work at Viacoin available or it hasn't released yet?

Perhaps its angels dancing on the heads of pins— but you can never check the validity of a signature without the scriptPubKeys, you can— however— check if the nlocktime is valid, e.g. and defer the more expensive operation of worrying about the signatures for transactions which have met their locktime requirements.

It also means that no transaction scheduling logic— e.g. code that decides if a transaction is locked yet needs to deal with scripts, and it means that the invariant that if a signature is invalid for a transaction is is always invalid, remains preserved (e.g. script remains a pure function with no non-deterministic inputs). E.g. you could still cache the entirety of script evaluation.

The downside with the criteria sniffing is that it's possible to have inputs with a mutually exclusive locktime type— e.g. two txins which can never be spent in the same transaction. This seemed inelegant to me, especially in contrast to the elegance of the rest of the approach. I still think it's better— just wish I had a way to avoid the risk of mutual exclusion. Obviously a receiver can just demand to use one type or the other.

Another odd concern with locktime in general is that it's incompatible with the natural solution to the y2038 problem (which isn't a real problem for the rest of the system since you can just unwrap header timestamps into 64 bit values).

Huh? You do have to check the scripts - the scripts are a new way for the transaction locktime to be bad. The advantage of your approach is that you don't need to add block height and current time inputs to EvalScript(), the source of quite a few lines of code changed in my patch. Basically it makes CHECKLOCKTIMEVERIFY similar to CHECKSIG in terms of the data needed to evaluate the opcode.

In any case, my plan right now is to use your approach, with the additional rule I suggested on IRC to check that tx.nLockTime < LOCKTIME_THRESHOLD if test_nLockTime < LOCKTIME_THRESHOLD to handle the two different ways of interpreting nLockTime. (block height and block time)

I circulated a patch for a different approach for Bitcoin a long time ago: https://people.xiph.org/~greg/OP_CHECKLOCKTIMEVERIFY.patch

(It's not complete and doesn't include the transition rules or cover some states, OTOH it simplifies code by not having to check the scripts (which may not even be inside the transaction itself) to know if the transaction is lock-time-good or not).

Organizational/political level, although that's sort of driven by technological constraints. Basically adding stuff to Bitcoin is risky - a mistake that takes the Bitcoin network down costs tens of thousands of dollars an hour - so naturally people are fairly conservative and getting everyone to adopt your proposed change is tough. Adding it to Viacoin OTOH isn't a big deal, because if you screw up you haven't done that much damage, so getting consensus to adopt the change shouldn't be too hard.

Generally to get something in you have to convince a good number of Core Devs and others that it's either a good idea, or at least not a bad idea to add a change.

Once it's added to Bitcoin Core it tends to get adopted.

As a software developer new to the bitcoin source I am really grateful for the work you have done in contributing to BTC and thanks for the reply.

Do you refer to the consensus as an organisation level obstacle or it is a technology term related to the blockchain ... sorry for the silly question :-) and I just want to make sure I understood you correctly.

My proof-of-concept patch was written for Bitcoin about a year ago; absolutely it could be integrated into Bitcoin Core. The only obstacle specific to Bitcoin is getting consensus.

Do you know if Peter Todd's OP_CHECKLOCKTIMEVERIFY will be ever integrated into the Bitcoin source or is it a VIACOIN specific design?

Should be such innovation considered for Bitcoin as well?