Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-26 📝 Original message:After a little more though ...
📅 Original date posted:2015-11-26
📝 Original message: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 at 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 at lists.linuxfoundation.org>
>To: "Btc Drak" <btcdrak at gmail.com>
>Cc: "Bitcoin Dev" <bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151126/6326f2b7/attachment.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org>
>To: "Btc Drak" <btcdrak at gmail.com>
>Cc: "Bitcoin Dev" <bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151126/6326f2b7/attachment.html>;