path: root/a5/b89c2c803090c11e7fdac62086f5a127a87b6b

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2CB2885
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 26 Nov 2015 22:23:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC27A115
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 26 Nov 2015 22:23:45 +0000 (UTC)
Received: from [192.168.2.16] (8-40-48-172.dynamic.skybest.com [8.40.48.172])
	by mail.bluematt.me (Postfix) with ESMTPSA id 58E7C5A719;
	Thu, 26 Nov 2015 22:23:43 +0000 (UTC)
In-Reply-To: <eme59eddfb-c410-4af4-b496-e3301ac9db85@platinum>
References: <eme59eddfb-c410-4af4-b496-e3301ac9db85@platinum>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----7DEIRDSKCCE0WWT32D1O70F78BYQKV"
Content-Transfer-Encoding: 8bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Thu, 26 Nov 2015 22:23:38 +0000
To: Eric Lombrozo <elombrozo@gmail.com>,
	Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Mark Friedenbach <mark@friedenbach.org>, Btc Drak <btcdrak@gmail.com>
Message-ID: <507FBD75-6A20-4057-A280-FA0E0A6C5689@mattcorallo.com>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	UC_GIBBERISH_OBFU autolearn=no 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: Thu, 26 Nov 2015 22:23:47 -0000

------7DEIRDSKCCE0WWT32D1O70F78BYQKV
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

Actually, with this argument I think CHECKSEQUENCEVERIFY is more appropriate. To an app developer, you're enforcing maturity by enforcing sequence. I think it's much more clear to app devs to say sequence here since it makes explicit how to create the transaction which passes the check, whereas saying maturity night be confusing.

On November 25, 2015 6:41:03 PM EST, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>As I said in an earlier post, a systems developer and an application 
>developer have very different perspectives on this. From the former's 
>perspective, 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 
>irrelevant to the application logic and there's no real gains to be had
>
>from attempting 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 
>intended 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 these ideas...and ultimately, 
>knowing the inner details of how the nSequence field is structured and 
>what the bits actually mean is irrelevant to someone 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 directly to developers and protocol designers the semantics they
>
>actually care about and also makes clear the relationship between 
>absolute and relative 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).
>
>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 
>greater 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>
>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 
>(BIP112)
>
>>Looks like I'm the long dissenting voice here? As the originator 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.nLockTime.
>>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 semantic change of 
>>CSV was justified in part because it relaxes all constraints over the 
>>values of these bits freeing them for other purposes in transaction 
>>validation and/or future extensions of the opcode semantics.
>>
>>Third, 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 CHECKSEQUENCEVERIFY has to do with sequencing 
>>execution pathways of script, so it's not a stretch in meaning. 
>>Previously CHECKMATURITYVERIFY was a hypothicated opcode 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
>exist. 
>>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 bitcoin-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.
>>>
>>>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is 
>>>specifically 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 available 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
>
>>>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 
>>>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 
>>>makes no sense to cram everything into one generic opcode.
>>>
>>>TL;DR: let's give BIP112 opcode a name that reflects it's actual 
>>>usecase rather than focusing on the bitcoin internals.
>>>
>>>[1] 
>>>https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>>>
>>>_______________________________________________
>>>bitcoin-dev mailing list
>>>bitcoin-dev@lists.linuxfoundation.org
>>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

------7DEIRDSKCCE0WWT32D1O70F78BYQKV
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head><style id="eMClientCss">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; padding-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weight: 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="auto" class="class">Actually, with this argument I think CHECKSEQUENCEVERIFY is more appropriate. To an app developer, you&#39;re enforcing maturity by enforcing sequence. I think it&#39;s much more clear to app devs to say sequence here since it makes explicit how to create the transaction which passes the check, whereas saying maturity night be confusing.<br><br><div class="gmail_quote">On November 25, 2015 6:41:03 PM EST, Eric Lombrozo via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">






<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 perspective, 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 irrelevant to the application logic and there's no real gains to be had from attempting to optimize for the inner workings when designing an application.</div>
<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 intended 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 these ideas...and ultimately, knowing the inner details of how the nSequence field is structured and what the bits actually mean is irrelevant to someone 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 directly to developers and protocol designers&nbsp;the semantics they actually care about and also makes clear the relationship between absolute and relative 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 greater 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="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</div>
<div>To: "Btc Drak" &lt;<a href="mailto:btcdrak@gmail.com">btcdrak@gmail.com</a>&gt;</div>
<div>Cc: "Bitcoin Dev" &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.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="xd0ad6736b39145a188160a962f50bc7f">
<blockquote class="cite2" cite="CAOG=w-v0_dfZS2=XfKQzRZ9Vq2Z2YqUO2_cuvOheuUrD4dbYtw@mail.gmail.com" type="cite">
<div dir="ltr">Looks like I'm the long dissenting voice here? As the originator 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.nLockTime.<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 semantic change of CSV was justified in part because it relaxes all constraints over the values of these bits freeing them for other purposes in transaction validation and/or future extensions of the opcode semantics.<br /><br />Third, 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 CHECKSEQUENCEVERIFY has to do with sequencing execution pathways of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY was a hypothicated opcode 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 exist. Again my objection would go away if we renamed nSequence, but I actually think the nSequence name is better...<br />
<div class="gmail_extra"><br />
<div class="gmail_quote">On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br />
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div dir="ltr">BIP68 introduces relative lock-time semantics to part of the nSequence field leaving the majority of bits undefined for other future applications. 
<div><br /></div>
<div>BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically 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 available 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 inputs 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 makes 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 usecase rather than focusing on the bitcoin internals.</div>
<div><br /></div>
<div>[1]&nbsp;<a href="https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223">https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223</a><br /></div></div><br />_______________________________________________<br />bitcoin-dev mailing list<br /><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /><br /></blockquote></div><br /></div></div></blockquote></div><p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br
/></pre></blockquote></div></body></html>
------7DEIRDSKCCE0WWT32D1O70F78BYQKV--