From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 657D4279 for ; 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 ; Wed, 25 Nov 2015 23:41:28 +0000 (UTC) Received: by pacdm15 with SMTP id dm15so71035170pac.3 for ; 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" To: "Mark Friedenbach" , "Btc Drak" Date: Wed, 25 Nov 2015 23:41:03 +0000 Message-Id: In-Reply-To: Reply-To: "Eric Lombrozo" 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: "Btc Drak" Cc: "Bitcoin Dev" 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 > 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
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.
 
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.
 
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.
 
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 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>
 
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.
 
- Eric
 
------ Original Message ------
From: "Mark Friedenbach via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org&g= t;
To: "Btc Drak" <btcdrak@gmail.= com>
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 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.

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

What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.n= LockTime.
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 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.

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.


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...

On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitc= oin-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.=20

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.

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.

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 make= s no sense to cram everything into one generic opcode.

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


_______________________________________________
bitcoin-dev= mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.= linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------=_MB8772E0DA-1BA2-458C-BD80-B3D609F457D0--