[bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

BIP68 introduces relative lock-time semantics to part of the nSequence
field leaving the majority of bits undefined for other future applications.

BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
limited to verifying transaction inputs according to BIP68's relative
lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
months limiting the number of bits used in BIP68 so they would be available
for future use cases, thus we have acknowledged there will be completely
different usecases that take advantage of unused nSequence bits.

For this reason I believe the BIP112 should be renamed specifically for
it's usecase, which is verifying the time/maturity of transaction inputs
relative to their inclusion in a block.

Suggestions:-

CHECKMATURITYVERIFY
RELATIVELOCKTIMEVERIFY
RCHECKLOCKTIMEVERIFY
RCLTV

We could of course softfork additional meaning into OP_CSV each time we add
new sequence number usecases, but that would become obscure and confusing.
We have already shown there is no shortage of opcodes so it makes no sense
to cram everything into one generic opcode.

TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
rather than focusing on the bitcoin internals.

[1]
https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223

[-- Attachment #2: Type: text/html, Size: 1714 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Tue, Nov 24, 2015 at 10:30:52AM +0000, Btc Drak via bitcoin-dev wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
> 
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
> limited to verifying transaction inputs according to BIP68's relative
> lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
> months limiting the number of bits used in BIP68 so they would be available
> for future use cases, thus we have acknowledged there will be completely
> different usecases that take advantage of unused nSequence bits.
> 
> For this reason I believe the BIP112 should be renamed specifically for
> it's usecase, which is verifying the time/maturity of transaction inputs
> relative to their inclusion in a block.
> 
> Suggestions:-
> 
> CHECKMATURITYVERIFY

Definitely this one.

Although I wouldn't rush to make the change just yet - I for one am busy
writing some test programs to actually use BIP112, and in theory they
might say the more general CSV concept is better.

Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
release.

-- 
'peter'[:-1]@petertodd.org
000000000000000008cd594ba6601fcc5e9e919b30630076c64657209b13c7b4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

I agree, I believe the first name that an op with equivalent functionality
had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged
sidechains' design.

I kind of dislike the check_x_verify naming pattern. We want all new
operands to return if whatever they're checking/verifying fails, fine. Do
we have to repeat this redundant naming pattern forever due to that
discovery?
I hope not, but if that's the case my vote is for CMV.
As said before, I believe the documentation and code comments can become
much more clear with this change.

[-- Attachment #2: Type: text/html, Size: 636 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Nov 24, 2015 1:21 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
> release.

While I agree we're not in a hurry, the more we wait, the longer docs (to
be modified later) will accumulate making the assumption that the name is
csv rather than op_maturity.

[-- Attachment #2: Type: text/html, Size: 502 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

From a system developer standpoint, CHECKMATURITYVERIFY ties together 
the semantics of this opcode with another existing feature in the system 
(coinbase maturity).

HOWEVER...

from an application developer standpoint, I think the concept of a 
timelock is more relevant. Maturity is a concept that was introduced for 
the sake of reducing the disruptive impact of reorgs. Miners would 
prefer to be able to spend the coins immediately, but instead they are 
forced to wait due to inherent limitations of the system. Timelocks, on 
the other hand, are typically used to control when funds can be moved. 
In these use cases, one or more of the parties involved explicitly want 
there to be a delay even if there were an idealized situation in which 
consensus is always reached instantaneously and there were never any 
reorgs.

Moreover, since we already have CLTV, adding RCLTV or some variant 
thereof makes the relationship between the two more explicit.

So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.

As for whether to explicitly use CHECK_..._VERIFY, consider that with 
segregated witness it will be possible to add opcodes that can push 
values onto the stack (rather than just hard failing or NOP), so there's 
something to be said for naming consistency.

- Eric



------ Original Message ------
From: "Jorge Timón" <bitcoin-dev@lists.linuxfoundation.org>
To: "Btc Drak" <btcdrak@gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
Sent: 11/24/2015 4:31:55 AM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
(BIP112)

>I agree, I believe the first name that an op with equivalent 
>functionality had was simply op_maturity.
>At least I remember we discussed such an opcode when discussing pegged 
>sidechains' design.
>
>I kind of dislike the check_x_verify naming pattern. We want all new 
>operands to return if whatever they're checking/verifying fails, fine. 
>Do we have to repeat this redundant naming pattern forever due to that 
>discovery?
>I hope not, but if that's the case my vote is for CMV.
>As said before, I believe the documentation and code comments can 
>become much more clear with this change.
>

[-- Attachment #2: Type: text/html, Size: 3531 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]

Looks like I'm the long dissenting voice here? As the originator of the
name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
appropriately chosen and why the proposed alternatives don't stand up.

First, the names are purposefully chosen to illustrate what they do:

What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.

Second, the semantics are not limited to relative lock-time / maturity
only. They both leave open ranges with possible, but currently undefined
future consensus-enforced behavior. We don't know what sort of future
behavior these values might trigger, but the associated opcodes are generic
enough to handle them:

CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
though such constraints have no meaning in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
while checking only 17 of the available 39 bits of both the operand and the
nSequence. Indeed the most recent semantic change of CSV was justified in
part because it relaxes all constraints over the values of these bits
freeing them for other purposes in transaction validation and/or future
extensions of the opcode semantics.

Third, single-byte opcode space is limited. There are less than 10 such
opcodes left. Maybe space won't be so precious in a post-segwitness world,
but I don't want to presume that just yet.


As for the alternatives, they capture only the initial use case of
nSequence. My objection would relax if nSequence were renamed, but I think
that would be too disruptive and unnecessary. In any case, the imagined use
cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
was a hypothicated opcode that directly checked the minimum age of inputs
of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
hypothicated opcode that would check a ficticious nRelativeLockTime field,
which does not exist. Again my objection would go away if we renamed
nSequence, but I actually think the nSequence name is better...

On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
> limited to verifying transaction inputs according to BIP68's relative
> lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
> months limiting the number of bits used in BIP68 so they would be available
> for future use cases, thus we have acknowledged there will be completely
> different usecases that take advantage of unused nSequence bits.
>
> For this reason I believe the BIP112 should be renamed specifically for
> it's usecase, which is verifying the time/maturity of transaction inputs
> relative to their inclusion in a block.
>
> Suggestions:-
>
> CHECKMATURITYVERIFY
> RELATIVELOCKTIMEVERIFY
> RCHECKLOCKTIMEVERIFY
> RCLTV
>
> We could of course softfork additional meaning into OP_CSV each time we
> add new sequence number usecases, but that would become obscure and
> confusing. We have already shown there is no shortage of opcodes so it
> makes no sense to cram everything into one generic opcode.
>
> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
> rather than focusing on the bitcoin internals.
>
> [1]
> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4867 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 7608 bytes --]

As I said in an earlier post, a systems developer and an application 
developer have very different perspectives on this. From the former's 
perspective, it is entirely sensible to name things based on basic 
features of the system's design (i.e. a field in the txin or tx that 
gets checked) - but from an app developer's perspective, what matters is 
how they will use a particular feature in an actual app.

I think that part of what systems developers should strive to do is to 
abstract out the inner minutiae of the system's guts and expose to app 
developers the clearest interface with which to develop apps. This is 
even more the case when the details of the inner workings are completely 
irrelevant to the application logic and there's no real gains to be had 
from attempting to optimize for the inner workings when designing an 
application.

From an app developer's perspective, I think it is pretty blatantly 
clear that relative timelock is *the* critical exposed functionality 
intended here. Now, one could argue that the satoshi script is still a 
systems level component of the system...but with the advent of overlay 
protocols such as payment channels and the Lightning Network, it is 
clear that we now require a new abstraction layer for reasoning about 
the higher level logic of the system that doesn't burden the protocol 
designer with having to know the intimate and esoteric details of the 
lower system levels. Of course, many of those who work on these higher 
level protocols will also be experts in the underlying system design. 
However, it greatly increases the learning curve and can easily 
frustrate people looking to work on these ideas...and ultimately, 
knowing the inner details of how the nSequence field is structured and 
what the bits actually mean is irrelevant to someone trying to design 
scripts for such applications.

We've already deployed another opcode, CHECKLOCKTIMEVERIFY, which does 
refer to the field name. However, in this particular situation, the 
field name reflects *far* more closely what the app developer actually 
cares about than nSequence, which to the app developer might as well be 
called foo. As such, I stick with my original vote - we should call the 
opcode RCHECKLOCKTIMEVERIFY, which has the advantage of communicating 
fairly directly to developers and protocol designers the semantics they 
actually care about and also makes clear the relationship between 
absolute and relative timelock...that's to say, the ability for the 
script designer to lock specific coins until either a specific moment in 
time or until a certain delay has passed since the coin output was 
created (added to blockchain).

Let's face it - the entire motivation behind BIP68/BIP112 is relative 
timelock. Explicitly calling the opcode RCHECKLOCKTIMEVERIFY will make 
life easier for everyone and will help sell the idea and help it gain 
greater acceptance more quickly; while stubbornly adhering to an 
esoteric detail that is only there for historical reasons will only 
continue to delay the idea's acceptance and adoptance.

- Eric

------ Original Message ------
From: "Mark Friedenbach via bitcoin-dev" 
<bitcoin-dev@lists.linuxfoundation.org>
To: "Btc Drak" <btcdrak@gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
Sent: 11/25/2015 3:05:50 PM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
(BIP112)

>Looks like I'm the long dissenting voice here? As the originator of the 
>name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was 
>appropriately chosen and why the proposed alternatives don't stand up.
>
>First, the names are purposefully chosen to illustrate what they do:
>
>What does CHECKLOCKTIMEVERIFY do? It verifies the range of 
>tx.nLockTime.
>What does CHECKSEQUENCEVERIFY do? It verifies the range of 
>txin.nSequence.
>
>Second, the semantics are not limited to relative lock-time / maturity 
>only. They both leave open ranges with possible, but currently 
>undefined future consensus-enforced behavior. We don't know what sort 
>of future behavior these values might trigger, but the associated 
>opcodes are generic enough to handle them:
>
>CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even 
>though such constraints have no meaning in Bitcoin.
>CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push 
>operand, while checking only 17 of the available 39 bits of both the 
>operand and the nSequence. Indeed the most recent semantic change of 
>CSV was justified in part because it relaxes all constraints over the 
>values of these bits freeing them for other purposes in transaction 
>validation and/or future extensions of the opcode semantics.
>
>Third, single-byte opcode space is limited. There are less than 10 such 
>opcodes left. Maybe space won't be so precious in a post-segwitness 
>world, but I don't want to presume that just yet.
>
>
>As for the alternatives, they capture only the initial use case of 
>nSequence. My objection would relax if nSequence were renamed, but I 
>think that would be too disruptive and unnecessary. In any case, the 
>imagined use cases for CHECKSEQUENCEVERIFY has to do with sequencing 
>execution pathways of script, so it's not a stretch in meaning. 
>Previously CHECKMATURITYVERIFY was a hypothicated opcode that directly 
>checked the minimum age of inputs of a transaction. The indirect naming 
>of CHECKSEQUENCEVERIFY on the other hand is due to its indirect 
>behavior. RELATIVELOCKTIMEVERIFY was also a hypothicated opcode that 
>would check a ficticious nRelativeLockTime field, which does not exist. 
>Again my objection would go away if we renamed nSequence, but I 
>actually think the nSequence name is better...
>
>On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev 
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>BIP68 introduces relative lock-time semantics to part of the nSequence 
>>field leaving the majority of bits undefined for other future 
>>applications.
>>
>>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is 
>>specifically limited to verifying transaction inputs according to 
>>BIP68's relative lock-time[1], yet the _name_ OP_CSV is much boarder 
>>than that. We spent months limiting the number of bits used in BIP68 
>>so they would be available for future use cases, thus we have 
>>acknowledged there will be completely different usecases that take 
>>advantage of unused nSequence bits.
>>
>>For this reason I believe the BIP112 should be renamed specifically 
>>for it's usecase, which is verifying the time/maturity of transaction 
>>inputs relative to their inclusion in a block.
>>
>>Suggestions:-
>>
>>CHECKMATURITYVERIFY
>>RELATIVELOCKTIMEVERIFY
>>RCHECKLOCKTIMEVERIFY
>>RCLTV
>>
>>We could of course softfork additional meaning into OP_CSV each time 
>>we add new sequence number usecases, but that would become obscure and 
>>confusing. We have already shown there is no shortage of opcodes so it 
>>makes no sense to cram everything into one generic opcode.
>>
>>TL;DR: let's give BIP112 opcode a name that reflects it's actual 
>>usecase rather than focusing on the bitcoin internals.
>>
>>[1] 
>>https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>>
>>_______________________________________________
>>bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 9456 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK <condition > VERIFY.

Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.

However, this name is ridiculously long, so at least some part will require abbreviation.

In typical script example usage, most sensible seems to be to abbreviate both CLTV and CRLTV.

- Eric

On November 24, 2015 5:14:55 PM PST, Eric Lombrozo <elombrozo@gmail.com> wrote:
From a system developer standpoint, CHECKMATURITYVERIFY ties together 
>the semantics of this opcode with another existing feature in the
>system 
>(coinbase maturity).
>
>HOWEVER...
>
>from an application developer standpoint, I think the concept of a 
>timelock is more relevant. Maturity is a concept that was introduced
>for 
>the sake of reducing the disruptive impact of reorgs. Miners would 
>prefer to be able to spend the coins immediately, but instead they are 
>forced to wait due to inherent limitations of the system. Timelocks, on
>
>the other hand, are typically used to control when funds can be moved. 
>In these use cases, one or more of the parties involved explicitly want
>
>there to be a delay even if there were an idealized situation in which 
>consensus is always reached instantaneously and there were never any 
>reorgs.
>
>Moreover, since we already have CLTV, adding RCLTV or some variant 
>thereof makes the relationship between the two more explicit.
>
>So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.
>
>As for whether to explicitly use CHECK_..._VERIFY, consider that with 
>segregated witness it will be possible to add opcodes that can push 
>values onto the stack (rather than just hard failing or NOP), so
>there's 
>something to be said for naming consistency.
>
>- Eric
>
>
>
>------ Original Message ------
>From: "Jorge Timón" <bitcoin-dev@lists.linuxfoundation.org>
>To: "Btc Drak" <btcdrak@gmail.com>
>Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
>Sent: 11/24/2015 4:31:55 AM
>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
>(BIP112)
>
>>I agree, I believe the first name that an op with equivalent 
>>functionality had was simply op_maturity.
>>At least I remember we discussed such an opcode when discussing pegged
>
>>sidechains' design.
>>
>>I kind of dislike the check_x_verify naming pattern. We want all new 
>>operands to return if whatever they're checking/verifying fails, fine.
>
>>Do we have to repeat this redundant naming pattern forever due to that
>
>>discovery?
>>I hope not, but if that's the case my vote is for CMV.
>>As said before, I believe the documentation and code comments can 
>>become much more clear with this change.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4312 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 8330 bytes --]

Actually, with this argument I think CHECKSEQUENCEVERIFY is more appropriate. To an app developer, you're enforcing maturity by enforcing sequence. I think it's much more clear to app devs to say sequence here since it makes explicit how to create the transaction which passes the check, whereas saying maturity night be confusing.

On November 25, 2015 6:41:03 PM EST, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>As I said in an earlier post, a systems developer and an application 
>developer have very different perspectives on this. From the former's 
>perspective, it is entirely sensible to name things based on basic 
>features of the system's design (i.e. a field in the txin or tx that 
>gets checked) - but from an app developer's perspective, what matters
>is 
>how they will use a particular feature in an actual app.
>
>I think that part of what systems developers should strive to do is to 
>abstract out the inner minutiae of the system's guts and expose to app 
>developers the clearest interface with which to develop apps. This is 
>even more the case when the details of the inner workings are
>completely 
>irrelevant to the application logic and there's no real gains to be had
>
>from attempting to optimize for the inner workings when designing an 
>application.
>
From an app developer's perspective, I think it is pretty blatantly 
>clear that relative timelock is *the* critical exposed functionality 
>intended here. Now, one could argue that the satoshi script is still a 
>systems level component of the system...but with the advent of overlay 
>protocols such as payment channels and the Lightning Network, it is 
>clear that we now require a new abstraction layer for reasoning about 
>the higher level logic of the system that doesn't burden the protocol 
>designer with having to know the intimate and esoteric details of the 
>lower system levels. Of course, many of those who work on these higher 
>level protocols will also be experts in the underlying system design. 
>However, it greatly increases the learning curve and can easily 
>frustrate people looking to work on these ideas...and ultimately, 
>knowing the inner details of how the nSequence field is structured and 
>what the bits actually mean is irrelevant to someone trying to design 
>scripts for such applications.
>
>We've already deployed another opcode, CHECKLOCKTIMEVERIFY, which does 
>refer to the field name. However, in this particular situation, the 
>field name reflects *far* more closely what the app developer actually 
>cares about than nSequence, which to the app developer might as well be
>
>called foo. As such, I stick with my original vote - we should call the
>
>opcode RCHECKLOCKTIMEVERIFY, which has the advantage of communicating 
>fairly directly to developers and protocol designers the semantics they
>
>actually care about and also makes clear the relationship between 
>absolute and relative timelock...that's to say, the ability for the 
>script designer to lock specific coins until either a specific moment
>in 
>time or until a certain delay has passed since the coin output was 
>created (added to blockchain).
>
>Let's face it - the entire motivation behind BIP68/BIP112 is relative 
>timelock. Explicitly calling the opcode RCHECKLOCKTIMEVERIFY will make 
>life easier for everyone and will help sell the idea and help it gain 
>greater acceptance more quickly; while stubbornly adhering to an 
>esoteric detail that is only there for historical reasons will only 
>continue to delay the idea's acceptance and adoptance.
>
>- Eric
>
>------ Original Message ------
>From: "Mark Friedenbach via bitcoin-dev" 
><bitcoin-dev@lists.linuxfoundation.org>
>To: "Btc Drak" <btcdrak@gmail.com>
>Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
>Sent: 11/25/2015 3:05:50 PM
>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY 
>(BIP112)
>
>>Looks like I'm the long dissenting voice here? As the originator of
>the 
>>name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was 
>>appropriately chosen and why the proposed alternatives don't stand up.
>>
>>First, the names are purposefully chosen to illustrate what they do:
>>
>>What does CHECKLOCKTIMEVERIFY do? It verifies the range of 
>>tx.nLockTime.
>>What does CHECKSEQUENCEVERIFY do? It verifies the range of 
>>txin.nSequence.
>>
>>Second, the semantics are not limited to relative lock-time / maturity
>
>>only. They both leave open ranges with possible, but currently 
>>undefined future consensus-enforced behavior. We don't know what sort 
>>of future behavior these values might trigger, but the associated 
>>opcodes are generic enough to handle them:
>>
>>CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
>
>>though such constraints have no meaning in Bitcoin.
>>CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push 
>>operand, while checking only 17 of the available 39 bits of both the 
>>operand and the nSequence. Indeed the most recent semantic change of 
>>CSV was justified in part because it relaxes all constraints over the 
>>values of these bits freeing them for other purposes in transaction 
>>validation and/or future extensions of the opcode semantics.
>>
>>Third, single-byte opcode space is limited. There are less than 10
>such 
>>opcodes left. Maybe space won't be so precious in a post-segwitness 
>>world, but I don't want to presume that just yet.
>>
>>
>>As for the alternatives, they capture only the initial use case of 
>>nSequence. My objection would relax if nSequence were renamed, but I 
>>think that would be too disruptive and unnecessary. In any case, the 
>>imagined use cases for CHECKSEQUENCEVERIFY has to do with sequencing 
>>execution pathways of script, so it's not a stretch in meaning. 
>>Previously CHECKMATURITYVERIFY was a hypothicated opcode that directly
>
>>checked the minimum age of inputs of a transaction. The indirect
>naming 
>>of CHECKSEQUENCEVERIFY on the other hand is due to its indirect 
>>behavior. RELATIVELOCKTIMEVERIFY was also a hypothicated opcode that 
>>would check a ficticious nRelativeLockTime field, which does not
>exist. 
>>Again my objection would go away if we renamed nSequence, but I 
>>actually think the nSequence name is better...
>>
>>On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev 
>><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>BIP68 introduces relative lock-time semantics to part of the
>nSequence 
>>>field leaving the majority of bits undefined for other future 
>>>applications.
>>>
>>>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is 
>>>specifically limited to verifying transaction inputs according to 
>>>BIP68's relative lock-time[1], yet the _name_ OP_CSV is much boarder 
>>>than that. We spent months limiting the number of bits used in BIP68 
>>>so they would be available for future use cases, thus we have 
>>>acknowledged there will be completely different usecases that take 
>>>advantage of unused nSequence bits.
>>>
>>>For this reason I believe the BIP112 should be renamed specifically 
>>>for it's usecase, which is verifying the time/maturity of transaction
>
>>>inputs relative to their inclusion in a block.
>>>
>>>Suggestions:-
>>>
>>>CHECKMATURITYVERIFY
>>>RELATIVELOCKTIMEVERIFY
>>>RCHECKLOCKTIMEVERIFY
>>>RCLTV
>>>
>>>We could of course softfork additional meaning into OP_CSV each time 
>>>we add new sequence number usecases, but that would become obscure
>and 
>>>confusing. We have already shown there is no shortage of opcodes so
>it 
>>>makes no sense to cram everything into one generic opcode.
>>>
>>>TL;DR: let's give BIP112 opcode a name that reflects it's actual 
>>>usecase rather than focusing on the bitcoin internals.
>>>
>>>[1] 
>>>https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>>>
>>>_______________________________________________
>>>bitcoin-dev mailing list
>>>bitcoin-dev@lists.linuxfoundation.org
>>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 10490 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Thu, Nov 26, 2015 at 01:32:58PM -0800, Eric Lombrozo via bitcoin-dev wrote:
> After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK <condition > VERIFY.
> 
> Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.
> 
> However, this name is ridiculously long, so at least some part will require abbreviation.
> 
> In typical script example usage, most sensible seems to be to abbreviate both CLTV and CRLTV.

...and CRLTV is hard to visually distinguish from CLTV. :(

You know, calling it AGEVERIFY is short and sweet.

-- 
'peter'[:-1]@petertodd.org
00000000000000000ef246c814f8cb8c1a26bc3c6cb1286bdbc5f4140ed3fc79

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Rusty Russell]

Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
>>From an app developer's perspective, I think it is pretty blatantly 
> clear that relative timelock is *the* critical exposed functionality 
> intended here.

As someone who actually developed scripts using CSV, I agree with Mark
(and Matt).  The relative locktime stuff isn't in this opcode, it's in
the nSequence calculation.

So, I vote to keep CSV called as it is.

Thanks,
Rusty.

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 6180 bytes --]

I was curious about there being only 10 single-byte opcodes left.  There
are ten single-byte OP_NOPx opcodes defined, but there are 15 opcodes that
"simply *do not exist anymore* in the protocol" because they are scary (had
bugs that "could crash any Bitcoin node if exploited" or "allowed anyone to
spend anyone's bitcoins").  There are also 66 single-byte values that are
currently reserved, 186 - 252 (0xba - 0xfc).

If the name OP_CHECKSEQUENCEVERIFY should not be changed, each of us has a
single best reason not to change it.  Finding other reasons suggests that
one's top reason isn't good enough.  See Nassim Taleb's book, Antifragile,
if that claim makes you curious.  The same goes for changing it.  In any
case, it is 178 (0xb2) and app developers can call it whatever they want.

It seems trivial to me since the following, in script.h, would neither slow
compilation nor confuse anyone, but could lead the curious to explore the
history and expand their knowledge:
OP_NOP3 = 0xb2,
OP_CHECKSEQUENCEVERIFY = OP_NOP3,
OP_CHECKMATURITYVERIFY = OP_NOP3, // A comment defending the alternative
name

I don't know the consensus here on leaving breadcrumbs in code comments
(and enum/variable names) for curious coders to use as inspiration for
studying the history, but I advocate it, since modern IDEs are fairly
well-equipped to make skipping or hiding comments easy.


On Wed, Nov 25, 2015 at 3:05 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Looks like I'm the long dissenting voice here? As the originator of the
> name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
> appropriately chosen and why the proposed alternatives don't stand up.
>
> First, the names are purposefully chosen to illustrate what they do:
>
> What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
> What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.
>
> Second, the semantics are not limited to relative lock-time / maturity
> only. They both leave open ranges with possible, but currently undefined
> future consensus-enforced behavior. We don't know what sort of future
> behavior these values might trigger, but the associated opcodes are generic
> enough to handle them:
>
> CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
> though such constraints have no meaning in Bitcoin.
> CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
> while checking only 17 of the available 39 bits of both the operand and the
> nSequence. Indeed the most recent semantic change of CSV was justified in
> part because it relaxes all constraints over the values of these bits
> freeing them for other purposes in transaction validation and/or future
> extensions of the opcode semantics.
>
> Third, single-byte opcode space is limited. There are less than 10 such
> opcodes left. Maybe space won't be so precious in a post-segwitness world,
> but I don't want to presume that just yet.
>
>
> As for the alternatives, they capture only the initial use case of
> nSequence. My objection would relax if nSequence were renamed, but I think
> that would be too disruptive and unnecessary. In any case, the imagined use
> cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
> of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
> was a hypothicated opcode that directly checked the minimum age of inputs
> of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
> hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
> hypothicated opcode that would check a ficticious nRelativeLockTime field,
> which does not exist. Again my objection would go away if we renamed
> nSequence, but I actually think the nSequence name is better...
>
> On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> BIP68 introduces relative lock-time semantics to part of the nSequence
>> field leaving the majority of bits undefined for other future applications.
>>
>> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is
>> specifically limited to verifying transaction inputs according to BIP68's
>> relative lock-time[1], yet the _name_ OP_CSV is much boarder than that. We
>> spent months limiting the number of bits used in BIP68 so they would be
>> available for future use cases, thus we have acknowledged there will be
>> completely different usecases that take advantage of unused nSequence bits.
>>
>> For this reason I believe the BIP112 should be renamed specifically for
>> it's usecase, which is verifying the time/maturity of transaction inputs
>> relative to their inclusion in a block.
>>
>> Suggestions:-
>>
>> CHECKMATURITYVERIFY
>> RELATIVELOCKTIMEVERIFY
>> RCHECKLOCKTIMEVERIFY
>> RCLTV
>>
>> We could of course softfork additional meaning into OP_CSV each time we
>> add new sequence number usecases, but that would become obscure and
>> confusing. We have already shown there is no shortage of opcodes so it
>> makes no sense to cram everything into one generic opcode.
>>
>> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
>> rather than focusing on the bitcoin internals.
>>
>> [1]
>> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 7893 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Eric Lombrozo]

[-- Attachment #1: Type: text/plain, Size: 3668 bytes --]

After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense.

It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin.

HOWEVER...there might be ways around this issue using segwit.

I've been pondering the possibility of adding an extra input vector to the prunable extra data that  comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash.

Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well.

I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications.

Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed.

This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to.

If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits.

I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet.

- Eric



On November 26, 2015 8:02:45 PM PST, Rusty Russell <rusty@rustcorp.com.au> wrote:
>Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>writes:
>>>From an app developer's perspective, I think it is pretty blatantly 
>> clear that relative timelock is *the* critical exposed functionality 
>> intended here.
>
>As someone who actually developed scripts using CSV, I agree with Mark
>(and Matt).  The relative locktime stuff isn't in this opcode, it's in
>the nSequence calculation.
>
>So, I vote to keep CSV called as it is.
>
>Thanks,
>Rusty.

[-- Attachment #2: Type: text/html, Size: 4411 bytes --]

Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Nov 26, 2015 12:06 AM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Again my objection would go away if we renamed nSequence, but I actually
think the nSequence name is better...

I suggested to rename nSequence to nMaturity on this list even before the
bips and implementations were started, probably too late now.
Before the implementation "let's think about those naming details later".
After the implementation "now it's too late, now we would need to change
the implementation, this renaming is now unnecessarily disruptive".

Reminds me of refactors and major releases:
At the beginning of the release "not now, this will disrupt development of
feature X"
After feature X is merged or replaced by feature Y: "too late in the
release cycle, refactors should be done only at the beginning, at the end
is 'too risky' ".
Sigh, I hope I find the "right time" (not both too soon and too late like
this time), next time...

[-- Attachment #2: Type: text/html, Size: 1186 bytes --]