CHECKLOCKTIMEVERIFY (BIP65) IsSuperMajority() soft-fork #6351

Merged
merged 3 commits into from Oct 23, 2015

Conversation

Projects
None yet
@petertodd
Contributor

petertodd commented Jun 28, 2015

Final step towards CLTV deployment on mainnet.

I've copied the logic and tests from the previous BIP66 (DERSIG) soft-fork line-by-line for ease of review; any code review applicable to BIP66 should be applicable to BIP65.

Once merged I'll prepare a backport of the soft-fork logic for the v0.10.x branch as well.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jun 29, 2015

Member

IMO bip65-cltv-p2p.py should be included in extended list in pull-tester/rpc-tests.sh. Adding it in the "normal" not extended list makes not much sense even if the script execution time is acceptable (<1min on a decent system).

Tested ACK.

Member

jonasschnelli commented Jun 29, 2015

IMO bip65-cltv-p2p.py should be included in extended list in pull-tester/rpc-tests.sh. Adding it in the "normal" not extended list makes not much sense even if the script execution time is acceptable (<1min on a decent system).

Tested ACK.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Jun 29, 2015

Member

I didn't reviewed the python tests, just the c++ part, but utACK on that part.

Member

jtimon commented Jun 29, 2015

I didn't reviewed the python tests, just the c++ part, but utACK on that part.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Jun 29, 2015

Member

utACK

Member

btcdrak commented Jun 29, 2015

utACK

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Jun 29, 2015

Contributor

@jonasschnelli Added the tests to the extended list. I didn't actually know about the pull-tester test list before, thanks!

Contributor

petertodd commented Jun 29, 2015

@jonasschnelli Added the tests to the extended list. I didn't actually know about the pull-tester test list before, thanks!

@mruddy

View changes

qa/rpc-tests/bip65-cltv.py
+ self.nodes[2].generate(1)
+ self.sync_all()
+ if (self.nodes[0].getblockcount() != cnt + 1051):
+ raise AssertionError("Failed to mine a version=3 block")

This comment has been minimized.

@mruddy

mruddy Jul 1, 2015

Contributor

Line 70 should be: Failed to mine a version=4 block

@mruddy

mruddy Jul 1, 2015

Contributor

Line 70 should be: Failed to mine a version=4 block

This comment has been minimized.

@petertodd

petertodd Jul 1, 2015

Contributor

Fixed.

@petertodd

petertodd Jul 1, 2015

Contributor

Fixed.

+ if (self.nodes[0].getblockcount() != cnt + 850):
+ raise AssertionError("Failed to mine 750 version=4 blocks")
+
+ # TODO: check that new CHECKLOCKTIMEVERIFY rules are not enforced

This comment has been minimized.

@mruddy

mruddy Jul 1, 2015

Contributor

In order to fill out the test for this "not enforced" TODO, you'll need to add a testable transaction to the 750th v4 block. As in your other script, you'd want to check that the new CLTV rules are not enforced on the 750th v4 block and that they are enforced on the 751st v4 block.

@mruddy

mruddy Jul 1, 2015

Contributor

In order to fill out the test for this "not enforced" TODO, you'll need to add a testable transaction to the 750th v4 block. As in your other script, you'd want to check that the new CLTV rules are not enforced on the 750th v4 block and that they are enforced on the 751st v4 block.

@@ -0,0 +1,175 @@
+#!/usr/bin/env python2
+#

This comment has been minimized.

@mruddy

mruddy Jul 1, 2015

Contributor

minor nit, just noticed that the copyright header was different in this file than the other

@mruddy

mruddy Jul 1, 2015

Contributor

minor nit, just noticed that the copyright header was different in this file than the other

@mruddy

This comment has been minimized.

Show comment
Hide comment
@mruddy

mruddy Jul 1, 2015

Contributor

Looks pretty good. Minor todo's with the python test scripts.

Needs some release notes, but you might have been waiting on those until later in the process. When you get to them, perhaps add a disclaimer that we may change the OP_NOP2 name decode to OP_CHECKLOCKTIMEVERIFY in script "asm" outputs in the future. That way we'll have the flexibility to make that change if/when we get to it.

Contributor

mruddy commented Jul 1, 2015

Looks pretty good. Minor todo's with the python test scripts.

Needs some release notes, but you might have been waiting on those until later in the process. When you get to them, perhaps add a disclaimer that we may change the OP_NOP2 name decode to OP_CHECKLOCKTIMEVERIFY in script "asm" outputs in the future. That way we'll have the flexibility to make that change if/when we get to it.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Jul 1, 2015

Contributor

So, @mruddy brought up two issues that are really the same as with the BIP66 tests: out of date copyright headers and TODO items that are out of date. The latter issue is pretty simple: bipdersig-p2p.py covers the missing test cases marked as "TODO" in bipdersig.py

I wanted to show I've replicated the exact same testing procedure done on BIP66 given that the code changes itself are also replicated exactly; if I'm going to fix these two nits I think it makes sense to fix them in the BIP66 tests first, in a separate commit that'll go first in this pull-req, so the two sets of tests can still be diffed directly to show exact equivalence. Makes sense?

@mruddy Yup, I'll add release notes later, and similarly, will look at what changing the NOP2 name will entail later. Right now I'm focused on making the minimal possible change that gets the job done so backporting the changes to v0.10.x (and probably v0.11.x) will be easy and clearly correct. v0.12.x can do the more invasive stuff of changing opcode names and what-not.

Contributor

petertodd commented Jul 1, 2015

So, @mruddy brought up two issues that are really the same as with the BIP66 tests: out of date copyright headers and TODO items that are out of date. The latter issue is pretty simple: bipdersig-p2p.py covers the missing test cases marked as "TODO" in bipdersig.py

I wanted to show I've replicated the exact same testing procedure done on BIP66 given that the code changes itself are also replicated exactly; if I'm going to fix these two nits I think it makes sense to fix them in the BIP66 tests first, in a separate commit that'll go first in this pull-req, so the two sets of tests can still be diffed directly to show exact equivalence. Makes sense?

@mruddy Yup, I'll add release notes later, and similarly, will look at what changing the NOP2 name will entail later. Right now I'm focused on making the minimal possible change that gets the job done so backporting the changes to v0.10.x (and probably v0.11.x) will be easy and clearly correct. v0.12.x can do the more invasive stuff of changing opcode names and what-not.

@mruddy

This comment has been minimized.

Show comment
Hide comment
@mruddy

mruddy Jul 2, 2015

Contributor

@petertodd I see what you're saying about trying to keep the diff compares as close and easy as possible. But, the diffs on the tests are necessarily going to be somewhat different. I wouldn't make updated BIP66 test cases part of this change set. My choice would be to make the minor cleanups to these tests so that they are cleaner when reviewed in isolation (and in the future, not within the context of how this change set compares to that of BIP66). I can see how line-only diffs vs some block or structural diffs might have some value to reduce dissonance though. So, however you want to handle it is OK with me.

About the decode name update, I agree, leave that until later. I was just saying that if you mention the upcoming change in the notes now, then it makes actually pushing it through later, easier. It's more of a busy work change anyways, so leave it for someone newer to the project than yourself to work on. It's good for someone newer to work on because of how it may affect various parts of the code base.

Contributor

mruddy commented Jul 2, 2015

@petertodd I see what you're saying about trying to keep the diff compares as close and easy as possible. But, the diffs on the tests are necessarily going to be somewhat different. I wouldn't make updated BIP66 test cases part of this change set. My choice would be to make the minor cleanups to these tests so that they are cleaner when reviewed in isolation (and in the future, not within the context of how this change set compares to that of BIP66). I can see how line-only diffs vs some block or structural diffs might have some value to reduce dissonance though. So, however you want to handle it is OK with me.

About the decode name update, I agree, leave that until later. I was just saying that if you mention the upcoming change in the notes now, then it makes actually pushing it through later, easier. It's more of a busy work change anyways, so leave it for someone newer to the project than yourself to work on. It's good for someone newer to work on because of how it may affect various parts of the code base.

@laanwj laanwj added the Validation label Jul 3, 2015

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Jul 4, 2015

Contributor

@mruddy Thanks! It'd be awesome for you to do that, and it'd be a good opportunity to have more eyes on the code too of course.

Anyway, I'll see what the other reviewers think re: the tests.

Contributor

petertodd commented Jul 4, 2015

@mruddy Thanks! It'd be awesome for you to do that, and it'd be a good opportunity to have more eyes on the code too of course.

Anyway, I'll see what the other reviewers think re: the tests.

@mruddy

This comment has been minimized.

Show comment
Hide comment
@mruddy

mruddy Jul 4, 2015

Contributor

I probably will, it's on my todo list.

Contributor

mruddy commented Jul 4, 2015

I probably will, it's on my todo list.

@mruddy

This comment has been minimized.

Show comment
Hide comment
@mruddy

mruddy Aug 2, 2015

Contributor

What do we need to do now to move this forward? Is this waiting on coordination with some other work, in need of more testing, or just baking and giving time for more review (it's been about a month since last update)?

Contributor

mruddy commented Aug 2, 2015

What do we need to do now to move this forward? Is this waiting on coordination with some other work, in need of more testing, or just baking and giving time for more review (it's been about a month since last update)?

if (block.nVersion >= 3 && IsSuperMajority(3, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {
flags |= SCRIPT_VERIFY_DERSIG;
}
+ // Start enforcing CHECKLOCKTIMEVERIFY, (BIP65) for block.nVersion=4
+ // blocks, when 75% of the network has upgraded:
+ if (block.nVersion >= 4 && IsSuperMajority(4, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {

This comment has been minimized.

@jtimon

jtimon Aug 4, 2015

Member

I still don't know why we wait for 75% to start using a policy rule.
I would do it from the start but only enforce it as a consensus rule after 95%.
I don't want to slow this down since it is a general softfork question (even if I'm right it can be solved after this PR), but I haven't been able to find an answer anywhere.

@jtimon

jtimon Aug 4, 2015

Member

I still don't know why we wait for 75% to start using a policy rule.
I would do it from the start but only enforce it as a consensus rule after 95%.
I don't want to slow this down since it is a general softfork question (even if I'm right it can be solved after this PR), but I haven't been able to find an answer anywhere.

This comment has been minimized.

@sipa

sipa Aug 4, 2015

Member

This is not a policy rule.

@sipa

sipa Aug 4, 2015

Member

This is not a policy rule.

This comment has been minimized.

@jtimon

jtimon Aug 4, 2015

Member

While individual miners apply it but still not enforce it as a consensus rule (ie reject blocks that don't apply it), it is just mining policy.
What am I missing?

@jtimon

jtimon Aug 4, 2015

Member

While individual miners apply it but still not enforce it as a consensus rule (ie reject blocks that don't apply it), it is just mining policy.
What am I missing?

This comment has been minimized.

@jtimon

jtimon Oct 15, 2015

Member

Seriously, what am I missing here? Why wait for 75% for enforcing the new rule in your own blocks (which by the way you are marking as being version 4)?

@jtimon

jtimon Oct 15, 2015

Member

Seriously, what am I missing here? Why wait for 75% for enforcing the new rule in your own blocks (which by the way you are marking as being version 4)?

This comment has been minimized.

@petertodd

petertodd Oct 16, 2015

Contributor

This code is executed against all blocks, not just blocks you created. If another miner creates a nVersion=4 block with an invalid use of CHECKLOCKTIMEVERIFY if you reject it without a majority of hashing power also rejecting it you'll get forked.

In fact, it might be a good idea to go the other way and remove the 75% rule, accepting invalid nVersion=4 blocks until 95%

@petertodd

petertodd Oct 16, 2015

Contributor

This code is executed against all blocks, not just blocks you created. If another miner creates a nVersion=4 block with an invalid use of CHECKLOCKTIMEVERIFY if you reject it without a majority of hashing power also rejecting it you'll get forked.

In fact, it might be a good idea to go the other way and remove the 75% rule, accepting invalid nVersion=4 blocks until 95%

This comment has been minimized.

@jtimon

jtimon Oct 16, 2015

Member

Thanks, for some reason I was fixated on this 75% threshold only affecting your own blocks, but this is ConnectBlock so it obviously affects all blocks. Yes, I wouldn't oppose to wait for the 95% here too. But with versionbits this disappears so is probably not worth to discuss this much.

@jtimon

jtimon Oct 16, 2015

Member

Thanks, for some reason I was fixated on this 75% threshold only affecting your own blocks, but this is ConnectBlock so it obviously affects all blocks. Yes, I wouldn't oppose to wait for the 95% here too. But with versionbits this disappears so is probably not worth to discuss this much.

This comment has been minimized.

@petertodd

petertodd Oct 16, 2015

Contributor

Yeah, I probably would have changed it to remove 75% a year ago... but at this stage I think it's harmless to leave in.

@petertodd

petertodd Oct 16, 2015

Contributor

Yeah, I probably would have changed it to remove 75% a year ago... but at this stage I think it's harmless to leave in.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Aug 4, 2015

Member

@mruddy I would say that, as usual, we're just waiting for more review, but IMO the harder-to-review parts have already been merged. I would really like that we move forward on this.

Member

jtimon commented Aug 4, 2015

@mruddy I would say that, as usual, we're just waiting for more review, but IMO the harder-to-review parts have already been merged. I would really like that we move forward on this.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Aug 4, 2015

Contributor

I think what's holding this up is a lack of political will to do yet another non-nVersion bits soft-fork upgrade; @gmaxwell has indicated a strong preference for never using IsSuperMajority() again.

On 4 August 2015 07:04:50 GMT-04:00, "Jorge Timón" notifications@github.com wrote:

@mruddy I would say that, as usual, we're just waiting for more review,
but IMO the harder-to-review parts have already been merged. I would
really like that we move forward on this.


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

Contributor

petertodd commented Aug 4, 2015

I think what's holding this up is a lack of political will to do yet another non-nVersion bits soft-fork upgrade; @gmaxwell has indicated a strong preference for never using IsSuperMajority() again.

On 4 August 2015 07:04:50 GMT-04:00, "Jorge Timón" notifications@github.com wrote:

@mruddy I would say that, as usual, we're just waiting for more review,
but IMO the harder-to-review parts have already been merged. I would
really like that we move forward on this.


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

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Aug 4, 2015

Member

It would seem a better plan to deploy this softfork now rather than waiting for nVersionbits code which isnt done yet. We know this method works and it doesnt get in the way of nVersionbits deployment later. Many players in the ecosystem are waiting for CLTV, I dont see why we should wait for perfection when we can deploy a much anticipated feature now. @sipa @gmaxwell @laanwj

Member

btcdrak commented Aug 4, 2015

It would seem a better plan to deploy this softfork now rather than waiting for nVersionbits code which isnt done yet. We know this method works and it doesnt get in the way of nVersionbits deployment later. Many players in the ecosystem are waiting for CLTV, I dont see why we should wait for perfection when we can deploy a much anticipated feature now. @sipa @gmaxwell @laanwj

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Aug 4, 2015

Member

Do we have any softfork ready to deploy in the coming 4 months? If no I don't think we need to wait for nVerionbits. I guess BIP62 is not ready yet.

Is there any plan to prevent a fork due to reckless SPV mining?

By the way, if BIP101 is implemented in Bitcoin XT, blocks will have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). In that case, it is not possible to support BIP101 without also supporting BIP65. @gavinandresen @mikehearn

Member

jl2012 commented Aug 4, 2015

Do we have any softfork ready to deploy in the coming 4 months? If no I don't think we need to wait for nVerionbits. I guess BIP62 is not ready yet.

Is there any plan to prevent a fork due to reckless SPV mining?

By the way, if BIP101 is implemented in Bitcoin XT, blocks will have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). In that case, it is not possible to support BIP101 without also supporting BIP65. @gavinandresen @mikehearn

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Aug 4, 2015

Member

Just for the record, @sipa ACK'd for IsSuperMajority() on the ML

Member

btcdrak commented Aug 4, 2015

Just for the record, @sipa ACK'd for IsSuperMajority() on the ML

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Aug 5, 2015

Contributor

@gmaxwell has indicated a strong preference for never using IsSuperMajority() again.

@gmaxwell can you confirm this?

Contributor

dcousens commented Aug 5, 2015

@gmaxwell has indicated a strong preference for never using IsSuperMajority() again.

@gmaxwell can you confirm this?

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Aug 5, 2015

Contributor

@dcousens this pull request shouldn't be held up waiting for a response from someone who has never participated in it.

@jl2012 there is BIP68, and the as-yet unnumbered CHECKSEQUENCEVERIFY and median-lock-time-past BIPs, all of which are related to CHECKTIMELOCKVERIFY and could be rolled out together...

Contributor

maaku commented Aug 5, 2015

@dcousens this pull request shouldn't be held up waiting for a response from someone who has never participated in it.

@jl2012 there is BIP68, and the as-yet unnumbered CHECKSEQUENCEVERIFY and median-lock-time-past BIPs, all of which are related to CHECKTIMELOCKVERIFY and could be rolled out together...

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Aug 6, 2015

Member

@maaku I think we could go with IsSuperMajority(). If BIP68 or other related BIPs are ready before BIP65 is completed, they could be considered as "addon" of BIP65. People will use nVersion=5 to support BIP65 and those addon.

Member

jl2012 commented Aug 6, 2015

@maaku I think we could go with IsSuperMajority(). If BIP68 or other related BIPs are ready before BIP65 is completed, they could be considered as "addon" of BIP65. People will use nVersion=5 to support BIP65 and those addon.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Aug 6, 2015

Member

@maaku I was thinking the same thing recently that rolling out CLTV and CSV opcodes as one upgrade would be ideal and most efficient but when are you planning to make the PR for CSV? Seems like the code is there in your fork...

If this is going to take you a while then in my opinion we should not hold up CLTV, but I think it would be a wasted opportunity not to bundle the features you list as one soft-fork.

Member

btcdrak commented Aug 6, 2015

@maaku I was thinking the same thing recently that rolling out CLTV and CSV opcodes as one upgrade would be ideal and most efficient but when are you planning to make the PR for CSV? Seems like the code is there in your fork...

If this is going to take you a while then in my opinion we should not hold up CLTV, but I think it would be a wasted opportunity not to bundle the features you list as one soft-fork.

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Aug 6, 2015

Contributor

The code is done, ready, tested, deployed to alpha testnet and known to
work.

What remains to be done is writing a BIP... Assistance is welcome if
someone wants to help speed this along. I'm being pulled in 10 different
directions and having trouble allocating the time necessary.

On Thu, Aug 6, 2015 at 3:42 PM, ฿tcDrak notifications@github.com wrote:

@maaku https://github.com/maaku I was thinking the same thing recently
that rolling out CLTV and CSV opcodes as one upgrade would be ideal and
most efficient but when are you planning to make the PR for CSV? Seems like
the code is there in your fork...

If this is going to take you a while then in my opinion we should not hold
up CLTV, but I think it would be a wasted opportunity not to bundle the
features you list as one soft-fork.


Reply to this email directly or view it on GitHub
#6351 (comment).

Contributor

maaku commented Aug 6, 2015

The code is done, ready, tested, deployed to alpha testnet and known to
work.

What remains to be done is writing a BIP... Assistance is welcome if
someone wants to help speed this along. I'm being pulled in 10 different
directions and having trouble allocating the time necessary.

On Thu, Aug 6, 2015 at 3:42 PM, ฿tcDrak notifications@github.com wrote:

@maaku https://github.com/maaku I was thinking the same thing recently
that rolling out CLTV and CSV opcodes as one upgrade would be ideal and
most efficient but when are you planning to make the PR for CSV? Seems like
the code is there in your fork...

If this is going to take you a while then in my opinion we should not hold
up CLTV, but I think it would be a wasted opportunity not to bundle the
features you list as one soft-fork.


Reply to this email directly or view it on GitHub
#6351 (comment).

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Aug 6, 2015

Member

+1 to @btcdrak 's thoughts.

Member

jtimon commented Aug 6, 2015

+1 to @btcdrak 's thoughts.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Aug 8, 2015

Contributor

Concept ACK and +1 to @btcdrak. I'd suggest holding off merging this until either CSV is ready or a week or two before a new release is going to freeze.

Contributor

TheBlueMatt commented Aug 8, 2015

Concept ACK and +1 to @btcdrak. I'd suggest holding off merging this until either CSV is ready or a week or two before a new release is going to freeze.

chriswheeler referenced this pull request in bitcoinxt/bitcoinxt Aug 10, 2015

Make fork warning use version bit masking, on the assumption that fro…
…m this point on all changes will be triggered by a bit in nVersion rather than an incrementing integer.
@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Aug 13, 2015

Member

+1 for @btcdrak would be awesome

Member

NicolasDorier commented Aug 13, 2015

+1 for @btcdrak would be awesome

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Aug 19, 2015

Member

Slush has found the first version 0x20000007 block on the mainnet. So there are only two options left for BIP65: 1. adopt the "version bit" BIP; 2. Use IsSuperMajority with vserion>0x20000007

Otherwise, there may be a premature birth of BIP65

In this case, I don't support IsSuperMajority as it will permanently invalidate a large range of nVersion

Member

jl2012 commented Aug 19, 2015

Slush has found the first version 0x20000007 block on the mainnet. So there are only two options left for BIP65: 1. adopt the "version bit" BIP; 2. Use IsSuperMajority with vserion>0x20000007

Otherwise, there may be a premature birth of BIP65

In this case, I don't support IsSuperMajority as it will permanently invalidate a large range of nVersion

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Aug 19, 2015

Member

@jl2012 You could also mask away bits 1,2,3, and 14 and have an integer comparison with blockversion>=8.

Member

btcdrak commented Aug 19, 2015

@jl2012 You could also mask away bits 1,2,3, and 14 and have an integer comparison with blockversion>=8.

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Aug 19, 2015

Member

@btcdrak I guess masking only bit 14 is enough? So one has to set bits 1,2,3,4 and 14 to support both BIP65 and BIP101? And bit 4 for BIP65 only?

Member

jl2012 commented Aug 19, 2015

@btcdrak I guess masking only bit 14 is enough? So one has to set bits 1,2,3,4 and 14 to support both BIP65 and BIP101? And bit 4 for BIP65 only?

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Aug 19, 2015

Member

@jl2012 By masking out 1,2,3 and 14 and nVersion=8 can be tested to be >=4 without wasting a bit for whenever we do adopt versionbits softfork signalling.

Member

btcdrak commented Aug 19, 2015

@jl2012 By masking out 1,2,3 and 14 and nVersion=8 can be tested to be >=4 without wasting a bit for whenever we do adopt versionbits softfork signalling.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Sep 16, 2015

Contributor

concept ACK. Big fan of CLTV and its benefits.

Contributor

jgarzik commented Sep 16, 2015

concept ACK. Big fan of CLTV and its benefits.

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Sep 16, 2015

Contributor

concept ACK here too. I have been waiting on this to be merged for a while now. Anything blocking it? (other than the soft-fork)

Contributor

dcousens commented Sep 16, 2015

concept ACK here too. I have been waiting on this to be merged for a while now. Anything blocking it? (other than the soft-fork)

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Sep 16, 2015

Contributor

FWIW currently BIP101/XT's nVersion bits aren't a concern to me, as the adoption is low enough to not trigger accidentally. Also, @gavinandresen confirmed w/ other devs recently that they'll add CLTV support to XT.

In terms of deployment, this IsSuperMajority() deployment mechanism is well tested and works, and there's no compatibility issue with it and a future nVersion bits deployment. (or subsequent IsSuperMajority() soft-forks) The only issue is if CLTV fails to gain acceptance, which right now I think is very unlikely.

So, ACK merge to get CLTV deployment on-track and in-progess.

Contributor

petertodd commented Sep 16, 2015

FWIW currently BIP101/XT's nVersion bits aren't a concern to me, as the adoption is low enough to not trigger accidentally. Also, @gavinandresen confirmed w/ other devs recently that they'll add CLTV support to XT.

In terms of deployment, this IsSuperMajority() deployment mechanism is well tested and works, and there's no compatibility issue with it and a future nVersion bits deployment. (or subsequent IsSuperMajority() soft-forks) The only issue is if CLTV fails to gain acceptance, which right now I think is very unlikely.

So, ACK merge to get CLTV deployment on-track and in-progess.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Sep 16, 2015

Member

I would prefer to wait for the other locktime PRs to be merged and soft fork them in as a bundle.

Member

btcdrak commented Sep 16, 2015

I would prefer to wait for the other locktime PRs to be merged and soft fork them in as a bundle.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Sep 16, 2015

Contributor

@btcdrak So basically IMO the advantage of that approach is it results in fewer overall # of soft-forks. Personally I'm kinda "meh" on that, but it's a reasonable position to hold.

Re: my schedule, I'm going to try to spend a day or two next week with the other locktime soft-forks and do a code review.

What I am a rather dubious about, is waiting until nVersion bits is finished, given that code hasn't even begun to be written yet - there's enough consensus for CLTV certainly to do another IsSuperMajority() soft-fork and get it there.

Contributor

petertodd commented Sep 16, 2015

@btcdrak So basically IMO the advantage of that approach is it results in fewer overall # of soft-forks. Personally I'm kinda "meh" on that, but it's a reasonable position to hold.

Re: my schedule, I'm going to try to spend a day or two next week with the other locktime soft-forks and do a code review.

What I am a rather dubious about, is waiting until nVersion bits is finished, given that code hasn't even begun to be written yet - there's enough consensus for CLTV certainly to do another IsSuperMajority() soft-fork and get it there.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Sep 16, 2015

Contributor

tl;dr: For deploying CLTV, lets not let perfect be the enemy of good...

Contributor

petertodd commented Sep 16, 2015

tl;dr: For deploying CLTV, lets not let perfect be the enemy of good...

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Sep 30, 2015

Contributor

NACK as-is. The optics, communication difficulties, and extra work of pulling off multiple lock-time related soft-forks are not being properly considered.

#6312 was proposed three months ago and has seen a good deal of review. The much simpler and less controversial #6564 and #6566 have been open for a month. Together these constitute a complete upgrade to the behavior of lock-time in bitcoin. Rolling out CLTV first will cause head-aches. In particular #6566 changes how lock-time validity is determined. Having to go back and fix infrastructure written against the current behavior if/when #6566 is rolled out will be a giant waste of everyone's time.

There was a plan discussed on the mailing list, this very issue, and the IRC development meeting a week ago to get reviews of the above mentioned PR's and do a point release just prior to 0.12. What happened to that plan?

Contributor

maaku commented Sep 30, 2015

NACK as-is. The optics, communication difficulties, and extra work of pulling off multiple lock-time related soft-forks are not being properly considered.

#6312 was proposed three months ago and has seen a good deal of review. The much simpler and less controversial #6564 and #6566 have been open for a month. Together these constitute a complete upgrade to the behavior of lock-time in bitcoin. Rolling out CLTV first will cause head-aches. In particular #6566 changes how lock-time validity is determined. Having to go back and fix infrastructure written against the current behavior if/when #6566 is rolled out will be a giant waste of everyone's time.

There was a plan discussed on the mailing list, this very issue, and the IRC development meeting a week ago to get reviews of the above mentioned PR's and do a point release just prior to 0.12. What happened to that plan?

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Sep 30, 2015

Member

@maaku I thought we already had a plan:

  1. Merge this before 0.12
  2. If nVersion bits is ready on time, deploy it using nVersion bits.
  3. If the maturity/rcltv/csv BIPs PRs are ready on time, deploy them all as a single softfork.

I believe we still have time to make all these 3 things for 0.12, I hope I'm not too optimistic.
But if we are not able to do so, I don't think BIP65 should wait more. I know softforks/hardforks don't need to coincide with major releases, but still, I don't see the problem with rolling the 2 changes in 2 different softforks if necessary.
You mention that #6566 changes how lock time validity is determined. Maybe some of that can be incorporated to BIP65 to safe the later head-aches?

Member

jtimon commented Sep 30, 2015

@maaku I thought we already had a plan:

  1. Merge this before 0.12
  2. If nVersion bits is ready on time, deploy it using nVersion bits.
  3. If the maturity/rcltv/csv BIPs PRs are ready on time, deploy them all as a single softfork.

I believe we still have time to make all these 3 things for 0.12, I hope I'm not too optimistic.
But if we are not able to do so, I don't think BIP65 should wait more. I know softforks/hardforks don't need to coincide with major releases, but still, I don't see the problem with rolling the 2 changes in 2 different softforks if necessary.
You mention that #6566 changes how lock time validity is determined. Maybe some of that can be incorporated to BIP65 to safe the later head-aches?

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Sep 30, 2015

Contributor

@maaku CLTV is written in such a way as to not change any of the semantics of anything other than OP_NOP2; whether or not CLTV is implemented has no bearing on CSV. Also, the statement "Together these constitute a complete upgrade to the behavior of lock-time in bitcoin." is incorrect: the upgrade is to the behavior of nSequence only. The behavior of nLockTime - and hence CLTV - remains unchanged. (modulo the median time soft-fork, which again being a soft-fork is independent of CLTV and the CLTV codebase itself)

Contributor

petertodd commented Sep 30, 2015

@maaku CLTV is written in such a way as to not change any of the semantics of anything other than OP_NOP2; whether or not CLTV is implemented has no bearing on CSV. Also, the statement "Together these constitute a complete upgrade to the behavior of lock-time in bitcoin." is incorrect: the upgrade is to the behavior of nSequence only. The behavior of nLockTime - and hence CLTV - remains unchanged. (modulo the median time soft-fork, which again being a soft-fork is independent of CLTV and the CLTV codebase itself)

@maaku

This comment has been minimized.

Show comment
Hide comment
@maaku

maaku Sep 30, 2015

Contributor

@petertodd I request that you please review #6566.

Contributor

maaku commented Sep 30, 2015

@petertodd I request that you please review #6566.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Sep 30, 2015

Contributor

@maaku I have looked at it. Like I say, whether or not CLTV is implemented has no impact on it.

Remember the only thing this pull-req does is enforce CLTV during block validation - code that already exists in git HEAD. CSV is a separate issue. For that matter, the unit tests for CLTV don't even change with any of these proposed changes!

Contributor

petertodd commented Sep 30, 2015

@maaku I have looked at it. Like I say, whether or not CLTV is implemented has no impact on it.

Remember the only thing this pull-req does is enforce CLTV during block validation - code that already exists in git HEAD. CSV is a separate issue. For that matter, the unit tests for CLTV don't even change with any of these proposed changes!

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Sep 30, 2015

Member

@jtimon Beginning the CLTV softfork now would only speed up CLTV deployment by a couple of months tops, which makes no sense to me if we can get the remaining locktime PRs merged in that same timeframe. But what is clear, is CLTV needs to be ready to go if CSV isnt ready in time. We should discuss this at the next dev meeting.

Member

btcdrak commented Sep 30, 2015

@jtimon Beginning the CLTV softfork now would only speed up CLTV deployment by a couple of months tops, which makes no sense to me if we can get the remaining locktime PRs merged in that same timeframe. But what is clear, is CLTV needs to be ready to go if CSV isnt ready in time. We should discuss this at the next dev meeting.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Sep 30, 2015

Member

@btcdrak I believe it was you who wrote the plan I explain above and I acked that plan #6351 (comment)

Member

jtimon commented Sep 30, 2015

@btcdrak I believe it was you who wrote the plan I explain above and I acked that plan #6351 (comment)

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 1, 2015

Contributor

@laanwj Re: your nit, I'll fix that once this is merged, because #6707 (comment)

Contributor

petertodd commented Oct 1, 2015

@laanwj Re: your nit, I'll fix that once this is merged, because #6707 (comment)

@CodeShark

This comment has been minimized.

Show comment
Hide comment
@CodeShark

CodeShark Oct 7, 2015

Contributor

I would like to merge #6747 first as it will make all soft fork deployments easier to review. I'd be happy to rebase this PR to #6747 myself. Otherwise ACK.

Contributor

CodeShark commented Oct 7, 2015

I would like to merge #6747 first as it will make all soft fork deployments easier to review. I'd be happy to rebase this PR to #6747 myself. Otherwise ACK.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 7, 2015

Contributor

I'm not sure that #6747 is safe to be honest... It moves a lot of code around in ways that aren't obviously correct. (by the standards of consensus critical code that is)

To review this pull-req, I'd suggest you follow the instructions in the commit message and verify that it's identical to the BIP66 pull-req; if you find any issues the BIP66 soft-fork would be similarly vulnerable.

On 7 October 2015 14:15:10 CEST, Eric Lombrozo notifications@github.com wrote:

I would like to merge #6747 first as it will make all soft fork
deployments easier to review. I'd be happy to rebase this PR to #6747
myself. Otherwise ACK.


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

Contributor

petertodd commented Oct 7, 2015

I'm not sure that #6747 is safe to be honest... It moves a lot of code around in ways that aren't obviously correct. (by the standards of consensus critical code that is)

To review this pull-req, I'd suggest you follow the instructions in the commit message and verify that it's identical to the BIP66 pull-req; if you find any issues the BIP66 soft-fork would be similarly vulnerable.

On 7 October 2015 14:15:10 CEST, Eric Lombrozo notifications@github.com wrote:

I would like to merge #6747 first as it will make all soft fork
deployments easier to review. I'd be happy to rebase this PR to #6747
myself. Otherwise ACK.


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

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 7, 2015

Member

I'm not sure that #6747 is safe to be honest... It moves a lot of code around in ways that aren't obviously correct. (by the standards of consensus critical code that is)

I checked consensus is maintained in #6747 by doing a full blockchain sync from the network on top of careful code review, but I'm not agreeing or disagreeing that #6747 needs to be part of this ISM roll-out.

Member

btcdrak commented Oct 7, 2015

I'm not sure that #6747 is safe to be honest... It moves a lot of code around in ways that aren't obviously correct. (by the standards of consensus critical code that is)

I checked consensus is maintained in #6747 by doing a full blockchain sync from the network on top of careful code review, but I'm not agreeing or disagreeing that #6747 needs to be part of this ISM roll-out.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 7, 2015

Contributor

@brcdrak Glad to hear! But again, its a big change... Anyway, I wrote the CLTV enable pull-req the way I did to make it maximally easy to review - if BIP66 was done right, this pull-req is done right.

On 7 October 2015 14:50:54 CEST, "฿tcDrak" notifications@github.com wrote:

I'm not sure that #6747 is safe to be honest... It moves a lot of
code around in ways that aren't obviously correct. (by the standards of
consensus critical code that is)

I checked consensus is maintained in #6747 by doing a full blockchain
sync from the network on top of careful code review.


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

Contributor

petertodd commented Oct 7, 2015

@brcdrak Glad to hear! But again, its a big change... Anyway, I wrote the CLTV enable pull-req the way I did to make it maximally easy to review - if BIP66 was done right, this pull-req is done right.

On 7 October 2015 14:50:54 CEST, "฿tcDrak" notifications@github.com wrote:

I'm not sure that #6747 is safe to be honest... It moves a lot of
code around in ways that aren't obviously correct. (by the standards of
consensus critical code that is)

I checked consensus is maintained in #6747 by doing a full blockchain
sync from the network on top of careful code review.


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

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Oct 7, 2015

Member
Member

sipa commented Oct 7, 2015

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Oct 7, 2015

Contributor

It also has to reject everything the old code rejected.

How would that be tested?

Contributor

dcousens commented Oct 7, 2015

It also has to reject everything the old code rejected.

How would that be tested?

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 7, 2015

Contributor

@dcousens With great difficulty.... That's one of the biggest challenges in changing consensus critical code.

Contributor

petertodd commented Oct 7, 2015

@dcousens With great difficulty.... That's one of the biggest challenges in changing consensus critical code.

@CodeShark

This comment has been minimized.

Show comment
Hide comment
@CodeShark

CodeShark Oct 7, 2015

Contributor

@petertodd I created a new PR #6774 and rebased #6747 atop it to make the relevant code changes as explicit as possible.I also added the mechanism for your PR to it without activating it yet so that we're ready to go with BIP65.

In any case, I don't want this to hold up deploying BIP65 and I understand you patterned it after BIP66. My intention was to make it even easier to compare the two (or any other soft fork deployments we make in the future, for that matter).

Consensus-critical code does indeed present challenges, but I hope the relatively few code movements in these PRs are very simple to follow, now. Checking its correctness should basically amount to ensuring there were no copy/paste errors.

I ran the comparison tool locally and it passed. It also passed Travis' barrage of tests.

Contributor

CodeShark commented Oct 7, 2015

@petertodd I created a new PR #6774 and rebased #6747 atop it to make the relevant code changes as explicit as possible.I also added the mechanism for your PR to it without activating it yet so that we're ready to go with BIP65.

In any case, I don't want this to hold up deploying BIP65 and I understand you patterned it after BIP66. My intention was to make it even easier to compare the two (or any other soft fork deployments we make in the future, for that matter).

Consensus-critical code does indeed present challenges, but I hope the relatively few code movements in these PRs are very simple to follow, now. Checking its correctness should basically amount to ensuring there were no copy/paste errors.

I ran the comparison tool locally and it passed. It also passed Travis' barrage of tests.

petertodd added some commits Jun 28, 2015

Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
Based on the earlier BIP66 soft-fork logic implemented by Pieter
Wuille's 5a47811
Add RPC tests for the CHECKLOCKTIMEVERIFY (BIP65) soft-fork
bip65-cltv.py is based on the earlier BIP66 soft-fork RPC test
implemented by Pieter Wuille's 819bcf9

bip65-cltv-p2p.py is based on the earlier BIP66 P2P test by Suhas
Daftuar's d76412b
@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 8, 2015

Contributor

Rebased and added BIP65 to getblockchaininfo softforks list.

Contributor

petertodd commented Oct 8, 2015

Rebased and added BIP65 to getblockchaininfo softforks list.

@CodeShark

This comment has been minimized.

Show comment
Hide comment
@CodeShark

CodeShark Oct 9, 2015

Contributor

@petertodd I created a branch demonstrating how we will deploy soft forks using #6747. The deployment logic for BIP65 can be conveniently compared side-by-side with that for BIP66, and future soft forks will also be possible to compare in this fashion regardless of whether we use IsSuperMajority or versionbits.

grep for "DEPLOY BIP65" to see the the hooks.

Contributor

CodeShark commented Oct 9, 2015

@petertodd I created a branch demonstrating how we will deploy soft forks using #6747. The deployment logic for BIP65 can be conveniently compared side-by-side with that for BIP66, and future soft forks will also be possible to compare in this fashion regardless of whether we use IsSuperMajority or versionbits.

grep for "DEPLOY BIP65" to see the the hooks.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Oct 22, 2015

Member

ACK

Member

btcdrak commented Oct 22, 2015

ACK

@laanwj laanwj merged commit 65ef372 into bitcoin:master Oct 23, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Oct 23, 2015

Merge pull request #6351
65ef372 Add BIP65 to getblockchaininfo softforks list (Peter Todd)
cde7ab2 Add RPC tests for the CHECKLOCKTIMEVERIFY (BIP65) soft-fork (Peter Todd)
287f54f Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic (Peter Todd)

@ryanxcharles ryanxcharles referenced this pull request in yoursnetwork/yours-bitcoin Oct 23, 2015

Closed

BIP65 - OP_CHECKLOCKTIMEVERIFY #16

NicolasDorier added a commit to MetacoSA/NBitcoin that referenced this pull request Oct 24, 2015

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Oct 24, 2015

Member

By making my test, I noticed something odd...

// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if(nLockTime > (long)txTo.LockTime)
    return false;

This means that if nLockTime == txTo.LockTime, then the script evaluate to true, which made me believe that I can spend "1000 OP_CLTV" from exactly block 1000.

However, such a transaction would not be final as IsFinalTx show :

    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;

We can see that if such transaction is propagated at block 1000 it will be rejected as NonFinal !
This mean that 1000 OP_CLTV can only be spent from block 1001, even if the script pass at block 1000.

Is this the expected behavior ? This seems kind of wierd...
I would have changed to

// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if(nLockTime > (long)txTo.LockTime - 1)
    return false;

So the script "1000 OP_CLTV" only pass from block 1001.

Member

NicolasDorier commented Oct 24, 2015

By making my test, I noticed something odd...

// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if(nLockTime > (long)txTo.LockTime)
    return false;

This means that if nLockTime == txTo.LockTime, then the script evaluate to true, which made me believe that I can spend "1000 OP_CLTV" from exactly block 1000.

However, such a transaction would not be final as IsFinalTx show :

    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;

We can see that if such transaction is propagated at block 1000 it will be rejected as NonFinal !
This mean that 1000 OP_CLTV can only be spent from block 1001, even if the script pass at block 1000.

Is this the expected behavior ? This seems kind of wierd...
I would have changed to

// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if(nLockTime > (long)txTo.LockTime - 1)
    return false;

So the script "1000 OP_CLTV" only pass from block 1001.

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Oct 24, 2015

Member

@NicolasDorier

So the script "1000 OP_CLTV" only pass from block 1001.

It is consistent with the meaning of nLockTime, i.e. a tx is final only after (not at or before) the nLockTime. "1000 OP_CLTV" means the output is spendable after block 1000.

1000 OP_CLTV can only be spent from block 1001, even if the script pass at block 1000.

It is always possible to create a valid script at block X, but is not final at block X. For example if the current height is 380000, a script of "390000 OP_CLTV" with nLockTime = 391000 is still valid but not final

Member

jl2012 commented Oct 24, 2015

@NicolasDorier

So the script "1000 OP_CLTV" only pass from block 1001.

It is consistent with the meaning of nLockTime, i.e. a tx is final only after (not at or before) the nLockTime. "1000 OP_CLTV" means the output is spendable after block 1000.

1000 OP_CLTV can only be spent from block 1001, even if the script pass at block 1000.

It is always possible to create a valid script at block X, but is not final at block X. For example if the current height is 380000, a script of "390000 OP_CLTV" with nLockTime = 391000 is still valid but not final

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Oct 24, 2015

Member

It is consistent with the meaning of nLockTime, i.e. a tx is final only after (not at or before) the nLockTime. "1000 OP_CLTV" means the output is spendable after block 1000.

This is what is not consistent ! "1000 OP_CLTV" is currently true if nLockTime is 1000. (1000 included)

Whereas a nLocktime of 1000 at block 1000 is not final as you rightly said " tx is final only after (not at or before)"

A consistent behavior would be "1000 OP_CLTV" false with a nLockTime of 1000.

Member

NicolasDorier commented Oct 24, 2015

It is consistent with the meaning of nLockTime, i.e. a tx is final only after (not at or before) the nLockTime. "1000 OP_CLTV" means the output is spendable after block 1000.

This is what is not consistent ! "1000 OP_CLTV" is currently true if nLockTime is 1000. (1000 included)

Whereas a nLocktime of 1000 at block 1000 is not final as you rightly said " tx is final only after (not at or before)"

A consistent behavior would be "1000 OP_CLTV" false with a nLockTime of 1000.

@jl2012

This comment has been minimized.

Show comment
Hide comment
@jl2012

jl2012 Oct 24, 2015

Member

A consistent behavior would be "1000 OP_CLTV" false with a nLockTime of 1000.

In that case you need a nLockTime of 1001 to spend "1000 OP_CLTV", which means unspendable until block 1002.

Anyway, by "consistent" I mean:

  1. With "X OP_CLTV", an output is spendable after block X.
  2. With nLockTime = X, the tx is valid after block X
Member

jl2012 commented Oct 24, 2015

A consistent behavior would be "1000 OP_CLTV" false with a nLockTime of 1000.

In that case you need a nLockTime of 1001 to spend "1000 OP_CLTV", which means unspendable until block 1002.

Anyway, by "consistent" I mean:

  1. With "X OP_CLTV", an output is spendable after block X.
  2. With nLockTime = X, the tx is valid after block X
@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Oct 25, 2015

Member
  1. With "X OP_CLTV", an output is spendable after block X.

No, with "X OP_CLTV" the output is spendable AT block X.

  1. With nLockTime = X, the tx is valid after block X

Yes, in other words nLockTime=X the tx is valid at block X+1.

This is the inconsistency.
Because of 2., it means that X OP_CLTV is spendable at X+1 even if the script returns true at X. This is what is not very coherent.

Member

NicolasDorier commented Oct 25, 2015

  1. With "X OP_CLTV", an output is spendable after block X.

No, with "X OP_CLTV" the output is spendable AT block X.

  1. With nLockTime = X, the tx is valid after block X

Yes, in other words nLockTime=X the tx is valid at block X+1.

This is the inconsistency.
Because of 2., it means that X OP_CLTV is spendable at X+1 even if the script returns true at X. This is what is not very coherent.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Oct 25, 2015

Member

@NicolasDorier it sounds like you are misunderstanding the design of OP_CLTV. There is no "return true" in it. It is a VERIFY op_code. It checks that the nlocktime field in the transaction agrees with the value on the stack, if it does-- it does nothing. If it does not, it terminates execution. It has no clue about the height of the blockchain, and if it did it would make script execution no long a pure function of the transaction, violate the layering between transactions and the blockchain, make it possible for a script to become invalid that was valid before, etc.

Member

gmaxwell commented Oct 25, 2015

@NicolasDorier it sounds like you are misunderstanding the design of OP_CLTV. There is no "return true" in it. It is a VERIFY op_code. It checks that the nlocktime field in the transaction agrees with the value on the stack, if it does-- it does nothing. If it does not, it terminates execution. It has no clue about the height of the blockchain, and if it did it would make script execution no long a pure function of the transaction, violate the layering between transactions and the blockchain, make it possible for a script to become invalid that was valid before, etc.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Oct 25, 2015

Member

@gmaxwell I understand that.
What I am saying is that from a script perpective "X OP_CLTV" means "can spend AT and AFTER block X".

While nLockTime=X means "can broadcast AT and AFTER block X+1".

Both of these means that "X OP_CLTV" will always been able to me spent at X+1, even if the X OP_CLTV will pass with nLockTime of X.

Well, I don't mind though, if it is the expected behavior, I have nothing to complain, sounds weird for me but this seems to be just a personal perspective rather than a mistake in the code. So I'm fine with it. I was just worried it was a mistake.

Member

NicolasDorier commented Oct 25, 2015

@gmaxwell I understand that.
What I am saying is that from a script perpective "X OP_CLTV" means "can spend AT and AFTER block X".

While nLockTime=X means "can broadcast AT and AFTER block X+1".

Both of these means that "X OP_CLTV" will always been able to me spent at X+1, even if the X OP_CLTV will pass with nLockTime of X.

Well, I don't mind though, if it is the expected behavior, I have nothing to complain, sounds weird for me but this seems to be just a personal perspective rather than a mistake in the code. So I'm fine with it. I was just worried it was a mistake.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Oct 25, 2015

Member

@NicolasDorier CLTV has nothing to do with blocks, X OP_CLTV means is "this transaction is invalid if X > the transaction's nLocktime field". What effect the nlocktime field has is largely a mystery to OP_CLTV.

Member

gmaxwell commented Oct 25, 2015

@NicolasDorier CLTV has nothing to do with blocks, X OP_CLTV means is "this transaction is invalid if X > the transaction's nLocktime field". What effect the nlocktime field has is largely a mystery to OP_CLTV.

@NicolasDorier

This comment has been minimized.

Show comment
Hide comment
@NicolasDorier

NicolasDorier Oct 25, 2015

Member

Ok now by thinking about it like you said,
If I want to say "Can spend this output at block X" then I need to use :
"X-1 OP_CTLV" and
at least nLockTime = X-1 when spending which is coherent.

I was indeed making things more complicated than they needed to be, I'm fine now !

Member

NicolasDorier commented Oct 25, 2015

Ok now by thinking about it like you said,
If I want to say "Can spend this output at block X" then I need to use :
"X-1 OP_CTLV" and
at least nLockTime = X-1 when spending which is coherent.

I was indeed making things more complicated than they needed to be, I'm fine now !

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Oct 25, 2015

Contributor

Great!

If you think there's a way to better explain CLTV in the BIP, pull-reqs welcome.

On 25 October 2015 12:24:41 GMT-04:00, Nicolas Dorier notifications@github.com wrote:

Ok now by thinking about it like you said,
If I want to say "Can spend this output at block X" then I need to use
:
"X-1 OP_CTLV" and
at least nLockTime = X-1 when spending which is coherent indeed.

I was indeed making things more complicated than they needed to be, I'm
fine now !


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

Contributor

petertodd commented Oct 25, 2015

Great!

If you think there's a way to better explain CLTV in the BIP, pull-reqs welcome.

On 25 October 2015 12:24:41 GMT-04:00, Nicolas Dorier notifications@github.com wrote:

Ok now by thinking about it like you said,
If I want to say "Can spend this output at block X" then I need to use
:
"X-1 OP_CTLV" and
at least nLockTime = X-1 when spending which is coherent indeed.

I was indeed making things more complicated than they needed to be, I'm
fine now !


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

@dcousens dcousens referenced this pull request in bitcoin/bips Oct 31, 2015

Merged

BIP65: Change to accepted status #233

bokobza pushed a commit to bokobza/StratisBitcoinFullNode that referenced this pull request Nov 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment