From: "Eric Lombrozo" <elombrozo@gmail.com>
To: =?utf-8?q?Jorge=20Tim=c3=b3n?= <jtimon@jtimon.cc>, "Btc Drak"
	<btcdrak@gmail.com>
Date: Wed, 25 Nov 2015 01:14:55 +0000
Message-Id: <em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum>
In-Reply-To: <CABm2gDqoq4pkXLS=4rKGOLGU0_0mq1_yMOHmLw73m=apiMRMpg@mail.gmail.com>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)
Precedence: list


--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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

HOWEVER...

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

Moreover, since we already have CLTV, adding RCLTV or some variant=20
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=20
segregated witness it will be possible to add opcodes that can push=20
values onto the stack (rather than just hard failing or NOP), so there's=
=20
something to be said for naming consistency.

- Eric



------ Original Message ------
From: "Jorge Tim=C3=B3n" <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=20
(BIP112)

>I agree, I believe the first name that an op with equivalent=20
>functionality had was simply op_maturity.
>At least I remember we discussed such an opcode when discussing pegged=20
>sidechains' design.
>
>I kind of dislike the check_x_verify naming pattern. We want all new=20
>operands to return if whatever they're checking/verifying fails, fine.=20
>Do we have to repeat this redundant naming pattern forever due to that=20
>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=20
>become much more clear with this change.
>
--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right:=
 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc=
 }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}
</STYLE>

<STYLE></STYLE>
</HEAD>
<BODY scroll=3Dauto class>
<DIV>From a system developer standpoint, CHECKMATURITYVERIFY ties together=
 the semantics of this opcode with another existing feature in the system=
 (coinbase maturity).</DIV>
<DIV>&nbsp;</DIV>
<DIV>HOWEVER...</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Moreover, since we already have CLTV, adding RCLTV or some variant =
thereof makes the relationship between the two&nbsp;more explicit.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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 somethin=
g to be said for naming consistency.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Eric</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>------ Original Message ------</DIV>
<DIV>From: "Jorge Tim=C3=B3n" &lt;<A href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt;</DIV>
<DIV>To: "Btc Drak" &lt;<A href=3D"mailto:btcdrak@gmail.com">btcdrak@gmail.=
com</A>&gt;</DIV>
<DIV>Cc: "Bitcoin Dev" &lt;<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt;</DIV>
<DIV>Sent: 11/24/2015 4:31:55 AM</DIV>
<DIV>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY=
 (BIP112)</DIV>
<DIV>&nbsp;</DIV>
<DIV id=3Dxe40f4e1a28394eee96200b907d68005b>
<BLOCKQUOTE class=3Dcite2 cite=3DCABm2gDqoq4pkXLS=3D4rKGOLGU0_0mq1_yMOHmLw7=
3m=3DapiMRMpg@mail.gmail.com type=3D"cite">
<P dir=3Dltr>I agree, I believe the first name that an op with equivalent=
 functionality had was simply op_maturity.<BR>At least I remember we discus=
sed such an opcode when discussing pegged sidechains' design.</P>
<P dir=3Dltr>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?<BR>I hope not, but if that's the case my vote is for CMV.<=
BR>As said before, I believe the documentation and code comments can become=
 much more clear with this change.</P></BLOCKQUOTE></DIV></BODY></HTML>
--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF--