Gavin and @NicolasDorier have a point: If there isn't actually scarcity of NOPs because OP_NOP10 could become OP_EX (if we run out), it makes sense to chose the original unparameterised CLTV version #6124 which also has been better tested. It's cleaner, more readable and results in a slightly smaller script which has also got to be a plus. On Tue, May 12, 2015 at 8:16 PM, Jorge Timón wrote: > This saves us ocodes for later but it's uglier and produces slightly > bigger scripts. > If we're convinced it's worth it, seems like the right way to do it, > and certainly cltv and rclv/op_maturity are related. > But let's not forget that we can always use this same trick with the > last opcode to get 2^64 brand new opcodes. > So I'm not convinced at all on whether we want #5496 or #6124. > But it would be nice to decide and stop blocking this. > > On Sat, May 9, 2015 at 11:12 AM, Peter Todd wrote: > > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: > >> > That said, if people have strong feelings about this, I would be > willing > >> > to make OP_CLTV work as follows: > >> > > >> > 1 OP_CLTV > >> > > >> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A > >> > future relative CLTV could then be a future soft-fork implemented as > >> > follows: > >> > > >> > 2 OP_CLTV > >> > > >> > On the bad side it'd be two or three days of work to rewrite all the > >> > existing tests and example code and update the BIP, and (slightly) > gets > >> > us away from the well-tested existing implementation. It also may > >> > complicate the codebase compared to sticking with just doing a Script > >> > v2.0, with the additional execution environment data required for v2.0 > >> > scripts cleanly separated out. But all in all, the above isn't too big > >> > of a deal. > >> > >> > >> Adding a parameter to OP_CLTV makes it much more flexible and is the > most > >> economic use of precious NOPs. > >> The extra time required is ok and it would be good to make this change > to > >> the PR in time for the feature freeze. > > > > Done! > > > > https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 > > > > -- > > 'peter'[:-1]@petertodd.org > > 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8 > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >