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 3470D7D for ; Wed, 25 Nov 2015 23:06:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E4308A for ; Wed, 25 Nov 2015 23:06:10 +0000 (UTC) Received: by iofh3 with SMTP id h3so68471608iof.3 for ; Wed, 25 Nov 2015 15:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2L8gpRhFf4VNZaMC7RQHwYe1/zhoT4NH0jPsxMOf0EQ=; b=rJfX2HMwXiIpfInXsRpZhUmLoKQaXibiHNlGIfWQoCDOVQoe5FbcsyOmEIweX8d141 vBblxjZ0STiUCht/h6Jl/+Dqz/9dKdPS5ZAOMrHhE4WL/IYHr8Pjzpwb6HjgtPEIqhnY I35TvTw0jTQd0rdR0hIC2hJQjRYgCGdKSU3PWwOW6w/3lZlH5gTPMpacvH/SrxmzuS1v 746UZWP2TomelZEWXUPWuodkTPY/bB1/aUzMquW0rPOOK1cW5BLe2rMRBu5GMPEVCdlW PpzVvUC0JArGWYBxdU4f/nRw9xIvi9EvCDz2gz7wx9+kMi2EuVk+NFJ7fAfL8JotAlCV Mk1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2L8gpRhFf4VNZaMC7RQHwYe1/zhoT4NH0jPsxMOf0EQ=; b=QssQVN0/EtpQaTJjBG7ZqxAXA8xMjx4YoqGr4BTDqvFUmuuqvUVkqf3I/Zohncmw7I rsyYLCOSeq//CEtxBfYO14heR7/52vXITack8d3ph0VDwv0BPeTGwKXcofpF1kfREvuC 4I+XhKhym2SuyyTBmJedYSReuiCgJtlPU7CAPIJVL2qJoJ9C+WsobCQ/4sQ5S1+XNjUk lHTADZmOTQU4yrEYHDgLvmb+z/KgPNjQj5vVt+qGxn8wal1mElLSgdfvl6N6VCO5+JSe gAj+P0aPF44Hr38nJK6fC+Lu2magoBUxaHjrJd3C0brDIZw7HJ8S65C64QklVZ4STfCA 1ZMw== X-Gm-Message-State: ALoCoQmUEzTKyFnJ5DiFNDMVFqohkzJKsMLQ3c3jOp6IgQQPGrEj1gOKxxQvtR2D02paY1SsKpgY X-Received: by 10.107.31.70 with SMTP id f67mr42853128iof.105.1448492769413; Wed, 25 Nov 2015 15:06:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.217 with HTTP; Wed, 25 Nov 2015 15:05:50 -0800 (PST) X-Originating-IP: [101.15.97.45] In-Reply-To: References: From: Mark Friedenbach Date: Wed, 25 Nov 2015 15:05:50 -0800 Message-ID: To: Btc Drak Content-Type: multipart/alternative; boundary=001a1140ff00fb19b805256580a9 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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:06:11 -0000 --001a1140ff00fb19b805256580a9 Content-Type: text/plain; charset=UTF-8 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 > > --001a1140ff00fb19b805256580a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like I'm the long dissenting voice here? As the = originator of the name CHECKSEQUENCEVERIFY, perhaps I can explain why the n= ame was appropriately chosen and why the proposed alternatives don't st= and 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 l= ock-time / maturity only. They both leave open ranges with possible, but cu= rrently undefined future consensus-enforced behavior. We don't know wha= t sort of future behavior these values might trigger, but the associated op= codes are generic enough to handle them:

CHECKLOCKTIMEVERIFY will pa= ss 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 va= lues of these bits freeing them for other purposes in transaction validatio= n and/or future extensions of the opcode semantics.

Third, single-by= te 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 ca= pture only the initial use case of nSequence. My objection would relax if n= Sequence were renamed, but I think that would be too disruptive and unneces= sary. 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 dir= ectly checked the minimum age of inputs of a transaction. The indirect nami= ng 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 objectio= n 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 l= ock-time semantics to part of the nSequence field leaving the majority of b= its undefined for other future applications.

BIP112 intr= oduces 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 usecas= es that take advantage of unused nSequence bits.

F= or this reason I believe the BIP112 should be renamed specifically for it&#= 39;s usecase, which is verifying the time/maturity of transaction inputs re= lative to their inclusion in a block.

Suggest= ions:-

CHECKMATURITYVERIFY
RELATIVEL= OCKTIMEVERIFY
RCHECKLOCKTIMEVERIFY
RCLTV
<= /div>

We could of course softfork additional meaning int= o OP_CSV each time we add new sequence number usecases, but that would beco= me obscure and confusing. We have already shown there is no shortage of opc= odes so it makes no sense to cram everything into one generic opcode.
=

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


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1140ff00fb19b805256580a9--