path: root/77/8a312210806b6ad4cebbd87154c3526f593e8b

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 657D4279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 23:41:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com
	[209.85.220.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42F1C8A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 23:41:28 +0000 (UTC)
Received: by pacdm15 with SMTP id dm15so71035170pac.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 25 Nov 2015 15:41:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
	:mime-version:content-type;
	bh=gltBiaAcwOxuDwNrNe8fLbbT5HQqM+qJh4T2i0n7Fu0=;
	b=wmgD4Zh8w8yvk/PVy73++SfevY7bO06fRdTJO7aj1ABvOYG1K2JknNhAVcuL80vLMG
	35mfyMU7Sm4/A2trB/ws3uNaIHdVZN9kr0U+uovKP59xL1KYIoQ4t01juykSHj0YNsgY
	fote0ZpqgXql5Qq4FinRldvpsenqetRwHIgS1a48/OrrMTNGsZzHnJ6c9X2zlwXLAj5e
	wzylyRp63xP2JyKJUzwjm3Bo21JI5pqHKjuGCiN1tmQVCUsZjIeTgTNLi4V4XLBrtil1
	IuxlXwJyvUoexGMybxsn3aniachCSreEOzcL3JSzqZmZT5fITmMWgeWFqIWp0xM2d3eq
	Mw4w==
X-Received: by 10.98.79.206 with SMTP id f75mr35643780pfj.24.1448494888015;
	Wed, 25 Nov 2015 15:41:28 -0800 (PST)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	134sm12360788pfa.30.2015.11.25.15.41.27
	(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
	Wed, 25 Nov 2015 15:41:27 -0800 (PST)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: "Mark Friedenbach" <mark@friedenbach.org>, "Btc Drak" <btcdrak@gmail.com>
Date: Wed, 25 Nov 2015 23:41:03 +0000
Message-Id: <eme59eddfb-c410-4af4-b496-e3301ac9db85@platinum>
In-Reply-To: <CAOG=w-v0_dfZS2=XfKQzRZ9Vq2Z2YqUO2_cuvOheuUrD4dbYtw@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="------=_MB8772E0DA-1BA2-458C-BD80-B3D609F457D0"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 23:41:29 -0000


--------=_MB8772E0DA-1BA2-458C-BD80-B3D609F457D0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

As I said in an earlier post, a systems developer and an application=20
developer have very different perspectives on this. From the former's=20
perspective, it is entirely sensible to name things based on basic=20
features of the system's design (i.e. a field in the txin or tx that=20
gets checked) - but from an app developer's perspective, what matters is=
=20
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=20
abstract out the inner minutiae of the system's guts and expose to app=20
developers the clearest interface with which to develop apps. This is=20
even more the case when the details of the inner workings are completely=
=20
irrelevant to the application logic and there's no real gains to be had=20
from attempting to optimize for the inner workings when designing an=20
application.

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

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

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

- Eric

------ Original Message ------
From: "Mark Friedenbach via bitcoin-dev"=20
<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=20
(BIP112)

>Looks like I'm the long dissenting voice here? As the originator of the=
=20
>name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was=20
>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=20
>tx.nLockTime.
>What does CHECKSEQUENCEVERIFY do? It verifies the range of=20
>txin.nSequence.
>
>Second, the semantics are not limited to relative lock-time / maturity=20
>only. They both leave open ranges with possible, but currently=20
>undefined future consensus-enforced behavior. We don't know what sort=20
>of future behavior these values might trigger, but the associated=20
>opcodes are generic enough to handle them:
>
>CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even=20
>though such constraints have no meaning in Bitcoin.
>CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push=20
>operand, while checking only 17 of the available 39 bits of both the=20
>operand and the nSequence. Indeed the most recent semantic change of=20
>CSV was justified in part because it relaxes all constraints over the=20
>values of these bits freeing them for other purposes in transaction=20
>validation and/or future extensions of the opcode semantics.
>
>Third, single-byte opcode space is limited. There are less than 10 such=
=20
>opcodes left. Maybe space won't be so precious in a post-segwitness=20
>world, but I don't want to presume that just yet.
>
>
>As for the alternatives, they capture only the initial use case of=20
>nSequence. My objection would relax if nSequence were renamed, but I=20
>think that would be too disruptive and unnecessary. In any case, the=20
>imagined use cases for CHECKSEQUENCEVERIFY has to do with sequencing=20
>execution pathways of script, so it's not a stretch in meaning.=20
>Previously CHECKMATURITYVERIFY was a hypothicated opcode that directly=20
>checked the minimum age of inputs of a transaction. The indirect naming=
=20
>of CHECKSEQUENCEVERIFY on the other hand is due to its indirect=20
>behavior. RELATIVELOCKTIMEVERIFY was also a hypothicated opcode that=20
>would check a ficticious nRelativeLockTime field, which does not exist.=
=20
>Again my objection would go away if we renamed nSequence, but I=20
>actually think the nSequence name is better...
>
>On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev=20
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>>BIP68 introduces relative lock-time semantics to part of the nSequence=
=20
>>field leaving the majority of bits undefined for other future=20
>>applications.
>>
>>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is=20
>>specifically limited to verifying transaction inputs according to=20
>>BIP68's relative lock-time[1], yet the _name_ OP_CSV is much boarder=20
>>than that. We spent months limiting the number of bits used in BIP68=20
>>so they would be available for future use cases, thus we have=20
>>acknowledged there will be completely different usecases that take=20
>>advantage of unused nSequence bits.
>>
>>For this reason I believe the BIP112 should be renamed specifically=20
>>for it's usecase, which is verifying the time/maturity of transaction=20
>>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=20
>>we add new sequence number usecases, but that would become obscure and=
=20
>>confusing. We have already shown there is no shortage of opcodes so it=
=20
>>makes no sense to cram everything into one generic opcode.
>>
>>TL;DR: let's give BIP112 opcode a name that reflects it's actual=20
>>usecase rather than focusing on the bitcoin internals.
>>
>>[1]=20
>>https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdb=
e4e55637dac75f3R1223
>>
>>_______________________________________________
>>bitcoin-dev mailing list
>>bitcoin-dev@lists.linuxfoundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
--------=_MB8772E0DA-1BA2-458C-BD80-B3D609F457D0
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>As I said in an earlier post, a systems developer and an application=
 developer have very different perspectives on this. From the former's pers=
pective, 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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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 irrele=
vant to the application logic and there's no real gains to be had from atte=
mpting to optimize for the inner workings when designing an application.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>From an app developer's perspective, I think it is pretty blatantly=
 clear that relative timelock is *the* critical exposed functionality inten=
ded 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 thes=
e ideas...and ultimately, knowing the inner details of how the nSequence=
 field is structured and what the bits actually mean is irrelevant to someo=
ne trying to design scripts for such applications.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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 dire=
ctly to developers and protocol designers&nbsp;the semantics they actually=
 care about and also makes clear the relationship between absolute and rela=
tive 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).<=
/DIV>
<DIV>&nbsp;</DIV>
<DIV>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 great=
er 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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Eric</DIV>
<DIV>&nbsp;</DIV>
<DIV>------ Original Message ------</DIV>
<DIV>From: "Mark Friedenbach via bitcoin-dev" &lt;<A href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</A>&g=
t;</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/25/2015 3:05:50 PM</DIV>
<DIV>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY=
 (BIP112)</DIV>
<DIV>&nbsp;</DIV>
<DIV id=3Dxd0ad6736b39145a188160a962f50bc7f>
<BLOCKQUOTE class=3Dcite2 cite=3DCAOG=3Dw-v0_dfZS2=3DXfKQzRZ9Vq2Z2YqUO2_cuv=
OheuUrD4dbYtw@mail.gmail.com type=3D"cite">
<DIV dir=3Dltr>Looks like I'm the long dissenting voice here? As the origin=
ator of the name CHECKSEQUENCEVERIFY, perhaps I can explain why the name=
 was appropriately chosen and why the proposed alternatives don't stand =
up.<BR><BR>First, the names are purposefully chosen to illustrate what they=
 do:<BR><BR>What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.n=
LockTime.<BR>What does CHECKSEQUENCEVERIFY do? It verifies the range of =
txin.nSequence.<BR><BR>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:<BR><BR>CHECKLOCKTIMEVERIFY will=
 pass an nSequence between 1985 and 2009, even though such constraints have=
 no meaning in Bitcoin.<BR>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 semanti=
c change of CSV was justified in part because it relaxes all constraints=
 over the values of these bits freeing them for other purposes in transacti=
on validation and/or future extensions of the opcode semantics.<BR><BR>Thir=
d, 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.<BR><BR><BR>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 CHECKSEQUENCEVERI=
FY has to do with sequencing execution pathways of script, so it's not a=
 stretch in meaning. Previously CHECKMATURITYVERIFY was a hypothicated opco=
de 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 exis=
t. Again my objection would go away if we renamed nSequence, but I actually=
 think the nSequence name is better...<BR>
<DIV class=3Dgmail_extra><BR>
<DIV class=3Dgmail_quote>On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitc=
oin-dev <SPAN dir=3Dltr>&lt;<A href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt;</SPAN> wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote style=3D"PADDING-LEFT: 1ex; MARGIN: 0px =
0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV dir=3Dltr>BIP68 introduces relative lock-time semantics to part of =
the nSequence field leaving the majority of bits undefined for other future=
 applications.=20
<DIV><BR></DIV>
<DIV>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specific=
ally 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 availabl=
e for future use cases, thus we have acknowledged there will be completely=
 different usecases that take advantage of unused nSequence bits.</DIV>
<DIV><BR></DIV>
<DIV>For this reason I believe the BIP112 should be renamed specifically=
 for it's usecase, which is verifying the time/maturity of transaction inpu=
ts relative to their inclusion in a block.</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>Suggestions:-</DIV>
<DIV><BR></DIV>
<DIV>CHECKMATURITYVERIFY<BR></DIV>
<DIV>RELATIVELOCKTIMEVERIFY<BR></DIV>
<DIV>RCHECKLOCKTIMEVERIFY<BR></DIV>
<DIV>RCLTV</DIV></DIV>
<DIV><BR></DIV>
<DIV>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 make=
s no sense to cram everything into one generic opcode.</DIV>
<DIV><BR></DIV>
<DIV>TL;DR: let's give BIP112 opcode a name that reflects it's actual useca=
se rather than focusing on the bitcoin internals.</DIV>
<DIV><BR></DIV>
<DIV>[1]&nbsp;<A href=3D"https://github.com/bitcoin/bitcoin/pull/6564/files=
#diff-be2905e2f5218ecdbe4e55637dac75f3R1223">https://github.com/bitcoin/bit=
coin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223</A><BR></DI=
V></DIV><BR>_______________________________________________<BR>bitcoin-dev=
 mailing list<BR><A href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</A><BR><A href=3D"https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev" rel=3Dnoreferrer>https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</A><BR><BR></BLOCKQUOTE></=
DIV><BR></DIV></DIV></BLOCKQUOTE></DIV></BODY></HTML>
--------=_MB8772E0DA-1BA2-458C-BD80-B3D609F457D0--