From: "Eric Lombrozo" <elombrozo@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>, "Btc Drak" <btcdrak@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)
Date: Wed, 25 Nov 2015 01:14:55 +0000 [thread overview]
Message-ID: <em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum> (raw)
In-Reply-To: <CABm2gDqoq4pkXLS=4rKGOLGU0_0mq1_yMOHmLw73m=apiMRMpg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2015-11-25 1:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 10:30 Btc Drak
2015-11-24 12:20 ` Peter Todd
2015-11-24 12:35 ` Jorge Timón
2015-11-24 12:31 ` Jorge Timón
2015-11-25 1:14 ` Eric Lombrozo [this message]
2015-11-26 21:32 ` Eric Lombrozo
2015-11-26 22:25 ` Peter Todd
2015-11-25 23:05 ` Mark Friedenbach
2015-11-25 23:41 ` Eric Lombrozo
2015-11-26 22:23 ` Matt Corallo
2015-11-27 4:02 ` Rusty Russell
2015-11-27 8:10 ` Eric Lombrozo
2015-11-27 4:08 ` Dave Scotese
2015-11-27 10:14 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=btcdrak@gmail$(echo .)com \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox