Okay I was about to wag my finger at you about making it IsStandard making the hardfork possible then I caught that you said passing. Your text is reasonably clear, I'm leaving this comment just in case someone else makes the same reading error.

I'm unsure how useful this is. There is some risk that people will mistake IsStandardness enforcement for adequate security. ("I tried to cheat and couldn't!"). OTOH, it sounds like a really interesting way to roll out softforking changes that paces the risk out somewhat better.

Okay I was about to wag my finger at you about making it IsStandard making the hardfork possible

To be clear, what exactly were you thinking I'd done?

I'm unsure how useful this is. There is some risk that people will mistake IsStandardness enforcement for adequate security.

Yeah, OTOH, the many of the applications for CLTV like micropayment channels already have some of that risk in that they're vulnerable to tx mutability. Not as seriously, but it's analogous.

Anyway, people who make that kind of mistake are probably making other mistakes that'll have them lose money anyway...

@petertodd My initial read of the description had me thinking you made CLTV IsStandard with no constraint on validity ("No code to start the process of a soft fork"), creating a risk for miners who might included invalid ones.

@gmaxwell Ah! Yeah, the NOPx discouragement code still applies, and in fact has a special case to make sure that if CLTV isn't enabled, NOP2 usage is discouraged: https://github.com/bitcoin/bitcoin/pull/5496/files#diff-be2905e2f5218ecdbe4e55637dac75f3R339

(DISCOURAGE_UPGRADABLE_NOPS is unittested too, so without that the unittests would fail)

@petertodd I have to agree with @gmaxwell, something about your PR wording immediately made me jump to the wrong conclusion too.

Any suggestions on wording this better?

Rebased on top of #5521

Just to know if I understand well.

You would want such mempool only check of CLTV out for 0.11, then, if it works without any notable problems and with some people building stuff on top of it, pushing that into the miners' rule for 0.12 ?

I'm asking because I intend to build some stuff on top of it, and not really motivated to run and adapt my code for a viacoin node. So I guess my only option left for now it to wait for 0.11 ?

Hopefully we enforce more than mempool for 0.11, but enforcing for mempool is a one-line change after merging the code (which we should move forward with, whether with mempool enforcement or not)

@petertodd Say the relay rule were widely deployed. What would be the plan if our we discovered that the exact rule construction wasn't the one we wanted?

I see. That's great to know !

I'll be waiting for 0.11, I don't have the time/skill to compile bitcoind from sources on linux.

Not a deal breaker though, I have my own script evaluator in .NET, I will port the CLTV + tests in it so I can test without a node. Not perfect, but I should be able to play with it truthfully enough.

Since it's just a relay rule at worst you just reject transactions with NOP2 from the mempool - the default behaviour - pick a new NOP#, and try out the new behaviour.

This means the implementation either does one or the other version - nice and clean - and neither version will interfere with the other. Of course both NOPs will make it into blocks, but that's not going to do us any harm as neither side has applied a soft-forking rule.

Now in many cases you don't need to do all this. For instance if we were to decide to make CLTV act against the block height/time rather than the tx one nodes with the old rule just reject txs from the less permissive version. You'd want to be careful re: DoS ban code, but we're finding that crops up over and over again anyway...

On 25 December 2014 17:25:58 GMT-05:00, Gregory Maxwell [email protected] wrote:

@petertodd Say the relay rule were widely deployed. What would be the
plan if our we discovered that the exact rule construction wasn't the
one we wanted?

---

Reply to this email directly or view it on GitHub:
#5496 (comment)

Rebased on master.

^ @jgarzik @btcdrak

ACK
I reviewed this and tested by creating this small RPC test:
https://gist.github.com/morcos/61084ac8a33363278638
(it requires a rebase to master first as it uses some of the new python tools)

Concept ACK - I think this falls on the side of being a useful soft fork upgrade half-step.

Of course, I would prefer to be more aggressive and go the entire way in one step.

@morcos Actually your RPC test should work on master now; pull-req #5981 has been merged.

@jgarzik We don't know if the most recent soft-fork will actually trigger prior to the release of v0.11, especially with @laanwj's proposed schedule. Merging this for v0.11 would at least get 95% of the code in the release, with actual enforcement happening in a v0.11.1 release. Getting off the rebase treadmill would also be nice.

While there has been discussion about a relative CLTV by @TheBlueMatt and @jtimon I don't think any of it really impacts implementation of an absolute CLTV, which is also needed. My most recent proposal is that absolute CLTV be implemented as-is, and relative CLTV be left for a future scripting system rethinking: http://www.mail-archive.com/[email protected]/msg07418.html

I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. The relative-CLTV idea is incredibly useful in systems like the proposed Lightning network, a proposal to build on top of payment challen hub-and-spoke networks (though Ive been unsuccessful in getting them to comment on this specific issue here, as they cant seem to get their paper rewritten).

@TheBlueMatt I replied on the mailing list: http://www.mail-archive.com/[email protected]/msg07442.html

Updated to add a type field for future soft-forks, e.g. a relative CLTV upgrade.

BIP updated: bitcoin/bips#153

CLTV demos: petertodd/checklocktimeverify-demos@148e91e

This should satisfy all objections. I propose this is merged for v0.11.0, and the actual soft-fork implemented in v0.11.1 once the ongoing BIP66 soft-fork triggers. (likely with @sipa's new nVersion feature flags BIP)

I have tested the code and sent the following tx fc6fa964c510e79b55ccea5bc8f21a505867b8ed286f6da02172bf8c297720dd on testnet using the following redeem script 632102b0efefbe8f8feaabc74ebde89928bfacc6471fe5f4db43b19c2ff4e58fdfc290ad670400ca9a3b51b16d6821032c8296c603d3c5802027d57a8f3ae382d7464abfda6f80e4f7d592ce23d696e7ac which decodes to OP_IF 02b0efefbe8f8feaabc74ebde89928bfacc6471fe5f4db43b19c2ff4e58fdfc290 OP_CHECKSIGVERIFY OP_ELSE 1000000000 1 OP_NOP2 OP_2DROP OP_ENDIF 032c8296c603d3c5802027d57a8f3ae382d7464abfda6f80e4f7d592ce23d696e7 OP_CHECKSIG

ACK.

The goal of doing that is to workaround the NOPX scarcity.
Would it not be better to take currently unused NOP for creating an "OP_EXT" instruction.

Then defines

0 OP_EXT would be for CHECKLOCKTIMEVERIFY,

1 OP_EXT would be for the next soft fork,

2 OP_EXT would be for the third soft fork, etc...

Your PR seems to only add extensibility for future relative CLTV, when I think, it can be broader without downside.

@NicolasDorier I am not sure I understand, the parameter that precedes OP_NOP2 already allows for any number of future CLTV implementations (e.g. relative CLTV and other implementations yet to be imagined), 1 OP_NOP2, 2 OP_NOP2, 3 OP_NOP2, 4 OP_NOP2, 5 OP_NOP2, 6 OP_NOP2, 7 OP_NOP2.... n OP_NOP2

What I mean is that you just changed the CLTV by requiring 1 OP_NOP2 for doing it.
You did it for NOP scarcity reason, and (not a big deal though), it broke the simpler code before.

The rational for adding the PUSH 1, was permitting new mode and implementation for CLTV in the future without wasting other NOP.

My point is that NOP scarcity is not a problem worth considering.

Because the day we use all nops except NOP10, we can just say that "NOP10" is a "OP_EXT" operation. And then consider "1 OP_EXT" like a "NOP11", and "2 OP_EXT" like a "NOP12".

So I see no problem with using NOP3 for RCLTV or other mode we might invent in the future.

Following what I just said, the latest PR is equivalent with choosing OP_EXT = NOP2, CLTV = NOP11 and RCLTV = NOP12, so why not waiting NOP10 for OP_EXT and just using NOP2 for CLTV and NOP3 for RCLTV.

I agree with @NicolasDorier, no reason to worry about NOP scarcity until we hit OP_NOP10-- and when we do, we can redefine OP_NOP10 as OP_EXT.

I think there is a good chance before then one of the OP_NOP's will be used to define an entirely different, redesigned scripting system, so we'll never get there.

Just to be clear, this is not an objection with the parametized CTLV. I just wanted to point out that the reason for doing it were flawed but I don't feel strongly about that.

I would prefer a parametized CLTV for the 15may freeze than delaying the CLTV one more time for the reasons I gave.

I opened a pull-req with the unparameterized version as well, #6124

I personally prefer the unparameterized version without the type argument; I agree with @gavinandresen that running out of NOP's isn't a major concern. More importantly though, let's pick one and get this merged for v0.11.0

@NicolasDorier It's a valid point. I don't particularly care either way, although the PR was adjusted to account for discussion on the mailing list. I'm fine with either. Prefer the original #6124

Seems we have rough consensus that a type parameter isn't needed, so closing in favor of #6124

Gah. I was not subscribed to this issue and didn't see the last few days debate.

Allow me to make an argument in favor of the type parameter. I have never seen opcode scarcity as the prime justification, and that was not the motivation for suggesting it as I did in an earlier PR. The reason I believe it is valuable to include the type parameter is for possible type checking efficiencies and future-proofing if the convention is adopted that OP_NOP(n) has the format [n n-1 ... 3 2 aux OP_NOPn] where the first parameter is the auxiliary opcode. So OP_NOP1 is used for opcodes which take no parameters [aux OP_NOP1]; OP_NOP2 for those like CLTV and RCLTV which take a single parameter [x aux OP_NOP2]; OP_NOP3 for those which take two parameters [y x aux OP_NOP3]; etc.

The implementation becomes a little bit cleaner as the OP_NOP(n) case statement can check that sufficient number of parameters are on the stack for all of its auxiliary opcodes, and future script authoring tools can have some rudimentary future-proof stack bounds checking.

I am strongly in favor of including the type parameter.

Also, I should mention that including the type parameter allows OP_CLTV and its relative variant to share nearly all of their implementation inline without a call-out. I hope to have code demonstrating this available in the very near future.

You can still reuse code in the checker (https://github.com/bitcoin/bitcoin/pull/6124/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1129), having 2 separated opcodes for cltv and rcltv doesn't preclude code reuse.

@maaku I think that's making a lot of premature assumptions about how the scripting system will be extended in the future. I think we're a lot more likely to implement an OP_MAST/OP_EVAL which just calls a new scheme, rather than continue extending what we have now.

re: code reuse, I'm not convinced that avoiding code reuse in cases where we're talking about just a few lines of consensus-critical code really makes all that much sense. As @gmaxwell gmaxwell commented a few months ago, if every detail of a codebase needs to be reviewed, having everything in one place can be easier than splitting things up across many different functions.

@petertodd the only non-aesthetic argument I've seen for multiple top-level opcodes instead of an extended opcode is that it saves 1 byte. However that byte is in the scriptSig, as there truly isn't any reason to use CLTV / RCLTV within a scriptPubKey. On the other hand, there may be future extensions to script which we want the use of an unallocated NOP in scriptPubKeys, I'd much rather take the hit of an extra byte in the scriptSig for CLTV/RCLTV than the UTXO if find later that we've exhausted the NOP space.

@maaku Hmm? It's quite likely that we'll see CLTV use in scriptPubKey's for payment channels for backup reasons, and absolutely guaranteed they'll be in redeemScripts. CLTV arguments are certainly always going to be in scriptPubKey's/redeemScript's as they rarely, if ever, are something where it makes sense to provide to spend a txout.

Anyway, the cost of an extra script version byte when it comes time to eventually do an OP_MAST is <3% of the total storage requirements to store a single UTXO.

@maaku I believe the only non-aesthetic argument in the other direction is no_op scarcity.
The reuse argument is invalid and your other "primary argument" seems aesthetic to me as well.

Non-aesthetic? In a wider context, agree w/ @petertodd RE "I think we're a lot more likely to implement an OP_MAST/OP_EVAL which just calls a new scheme, rather than continue extending what we have now."

e.g. OP_ETHEREUM would likely just require one opcode.

Even though I'm the first to argue in favor of a script replacement, when discussing changes to the existing script system I think it is prudent to assume that we'll be stuck with script for much longer than we anticipate. I think that conservatism favors a two-byte extension opcode: (1) it leaves more single byte nopcodes available for OP_EVAL-like extensions which benefit more from brevity, and (2) if done in a certain way, it allows future-proof stack bounds checking in script authoring tools or policy checks.

Without a full script replacement why would you ever need any script authoring tools? Script is just too limited to warrant that kind of complexity right now - there are literally less than a dozen or so basic script fragments that are useful.

On 16 May 2015 17:50:58 GMT-04:00, Mark Friedenbach [email protected] wrote:

Even though I'm the first to argue in favor of a script replacement,
when discussing changes to the existing script system I think it is
prudent to assume that we'll be stuck with script for much longer than
we anticipate. I think that conservatism favors a two-byte extension
opcode: (1) it leaves more single byte nopcodes available for
OP_EVAL-like extensions, and (2) it done in a certain way, it allows
future-proof stack bounds checking in script authoring tools or policy
checks.

---

Reply to this email directly or view it on GitHub:
#5496 (comment)

(1) it leaves more single byte nopcodes available for OP_EVAL-like extensions which benefit more from brevity,

Let's reserve OP_16 for script2.0 and let's assume that will take ages to be deployed.
Let's reserve OP_15 for taking the extra byte instead of doing it now, that will give us 255 more instructions.
Let's reserve OP_15 255 to take a short (2 bytes) in a similar way, that will give us 65536 more.
Let's reserve OP_15 255 65535 to take 4 bytes, that will give us 4294967296 more.
Etc, etc...
I really think we're safe.

(2) if done in a certain way, it allows future-proof stack bounds checking in script authoring tools or policy checks.

This is the part I'm not understanding. I'm missing why the reuse of "stack bounds checks" is not just bikeshedding and how the alternative is any less "future-proof".
Can you elaborate on this?

Make OP_NOP2 fail unless there are at least two items on the stack. It doesn't care what items, but they must be >=2. At this point a script tool, or relay policy is written that has no idea what the extra OP_NOP2 functionality is, but it knows that at the point OP_NOP2 is executed, there must be two items on the stack. A script compiler or transaction validator throws an error if it can determine that the stack would contain less than two items when the OP_NOP2 is executed. For some scriptPubKeys, the minimum number of pushes in the scriptSig could be inferred based on this and other constraints.

Later, CLTV is implemented but none of this software has been updated to understand the new rules yet. Nevertheless, the compiler still throws an error when the lock time parameter is not provided, relay nodes drop the same transactions, and your script type checker helpfully reminds you that you are probably missing a value for that unrecognised OP_NOP2 extended instruction.

It's a very limited form of type checking, and not nearly as useful as it could be in a much better designed language. But it is an improvement over the status quo for existing script.

@maaku Relay nodes already drop transactions that use unknown opcodes; in fact I should have done that for this type patch... shows it's an ill-advised idea IMO - yet another thing to take into account over the simpler "one-opcode one-function" principle.

Again, I'm just not seeing the value of things like "type checkers" for the scripting language right now, given how utterly simple it is. Equally, in the future if the choice was to make the scripting language more or less complex for the sake of type checking vs. getting consensus, I'd 100% choose the latter, always. People are free to write scripts that are bad ideas; the important thing is that the consensus critical codebase stay simple to ensure we don't make mistakes that affect everyone. (like the one I made above!)