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 4A1FA2C for ; Fri, 27 Nov 2015 04:08:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7841A9 for ; Fri, 27 Nov 2015 04:08:35 +0000 (UTC) Received: by oies6 with SMTP id s6so56442305oie.1 for ; Thu, 26 Nov 2015 20:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2ppwQsxFAkjojzW397+GPAzEGhnd22SZLAi5/c+/gTY=; b=oPt80cFMSjJ7ko1XEdJC6PGQy7XPRNQ2+vlRIA1X1Rdoee/Kdj+95/9kPmkU9dWisU bur3NLvUE3ULDZ23NeZegz0xi/8QBBzO8uHqnlcmWTwkF7df8/o5d+fdxq1ObjDhgmC3 TNVUbZleLSeS8eDS2eubAhDCWEeCLsoY/b3P/Kf0HHTH+5OFZAJ44ICftb7Tue+DXYa7 6232VoJzhsNo4J+IZ6BFwLuq4qzQEw35ICnk98EPDIaUkMMhJaJpe0gcSnrnsNe1C0Q5 A/r+k3qMpbMpj8wh0l3521LaeUq0DlDX13wRaa0GBP7HKTrYrC25RRauBKTsByVBoUu1 sXAA== MIME-Version: 1.0 X-Received: by 10.202.227.199 with SMTP id a190mr27313857oih.35.1448597315243; Thu, 26 Nov 2015 20:08:35 -0800 (PST) Sender: dscotese@gmail.com Received: by 10.60.16.39 with HTTP; Thu, 26 Nov 2015 20:08:35 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2015 20:08:35 -0800 X-Google-Sender-Auth: dwkDPZbltCrIVDlDdcBK-8u3rUc Message-ID: From: Dave Scotese To: Mark Friedenbach Content-Type: multipart/alternative; boundary=001a11407c8c65d47605257dd83d X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Fri, 27 Nov 2015 04:42:06 +0000 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: Fri, 27 Nov 2015 04:08:37 -0000 --001a11407c8c65d47605257dd83d Content-Type: text/plain; charset=UTF-8 I was curious about there being only 10 single-byte opcodes left. There are ten single-byte OP_NOPx opcodes defined, but there are 15 opcodes that "simply *do not exist anymore* in the protocol" because they are scary (had bugs that "could crash any Bitcoin node if exploited" or "allowed anyone to spend anyone's bitcoins"). There are also 66 single-byte values that are currently reserved, 186 - 252 (0xba - 0xfc). If the name OP_CHECKSEQUENCEVERIFY should not be changed, each of us has a single best reason not to change it. Finding other reasons suggests that one's top reason isn't good enough. See Nassim Taleb's book, Antifragile, if that claim makes you curious. The same goes for changing it. In any case, it is 178 (0xb2) and app developers can call it whatever they want. It seems trivial to me since the following, in script.h, would neither slow compilation nor confuse anyone, but could lead the curious to explore the history and expand their knowledge: OP_NOP3 = 0xb2, OP_CHECKSEQUENCEVERIFY = OP_NOP3, OP_CHECKMATURITYVERIFY = OP_NOP3, // A comment defending the alternative name I don't know the consensus here on leaving breadcrumbs in code comments (and enum/variable names) for curious coders to use as inspiration for studying the history, but I advocate it, since modern IDEs are fairly well-equipped to make skipping or hiding comments easy. On Wed, Nov 25, 2015 at 3:05 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a11407c8c65d47605257dd83d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was curious about there being o= nly 10 single-byte opcodes left.=C2=A0 There are ten single-byte OP_NOPx op= codes defined, but there are 15 opcodes that "simply do not exist a= nymore in the protocol" because they are scary (had bugs that &quo= t;could crash any Bitcoin node if exploited" or "allowed anyone t= o spend anyone's bitcoins").=C2=A0 There are also 66 single-byte v= alues that are currently reserved, 186 - 252 (0xba - 0xfc).

If the name OP_CHECKSEQUENCEVERIFY should not be changed, each of us has= a single best reason not to change it.=C2=A0 Finding other reasons suggest= s that one's top reason isn't good enough.=C2=A0 See Nassim Taleb&#= 39;s book, Antifragile, if that claim makes you curious.=C2=A0 The same goe= s for changing it.=C2=A0 In any case, it is 178 (0xb2) and app developers c= an call it whatever they want.

It seems trivial to me sin= ce the following, in script.h, would neither slow compilation nor confuse a= nyone, but could lead the curious to explore the history and expand their k= nowledge:
OP_NOP3 =3D 0xb2,
OP_CHECKSEQUENCEVERIFY =3D OP_NOP3,=
OP_CHECKMATURITYVERIFY =3D OP_NOP3, // A comment defending the alternat= ive name

I don't know the consensus here on leaving b= readcrumbs in code comments (and enum/variable names) for curious coders to= use as inspiration for studying the history, but I advocate it, since mode= rn IDEs are fairly well-equipped to make skipping or hiding comments easy.<= br>


On Wed, Nov 25, 2015 at 3:05 PM, Mark = Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Looks like I'm the long dissenting voice here? As the origin= ator of the name CHECKSEQUENCEVERIFY, perhaps I can explain why the name wa= s appropriately chosen and why the proposed alternatives don't stand up= .

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

What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLo= ckTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.= nSequence.

Second, the semantics are not limited to relative lock-ti= me / maturity only. They both leave open ranges with possible, but currentl= y 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 meani= ng in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-b= yte push operand, while checking only 17 of the available 39 bits of both t= he operand and the nSequence. Indeed the most recent semantic change of CSV= was justified in part because it relaxes all constraints over the values o= f these bits freeing them for other purposes in transaction validation and/= or future extensions of the opcode semantics.

Third, single-byte opc= ode 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 nSequen= ce 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 meani= ng. 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. RELA= TIVELOCKTIMEVERIFY was also a hypothicated opcode that would check a fictic= ious nRelativeLockTime field, which does not exist. Again my objection woul= d go away if we renamed nSequence, but I actually think the nSequence name = is better...

O= n 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 unde= fined for other future applications.

BIP112 introduces o= pcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically limited to verifyin= g transaction inputs according to BIP68's relative lock-time[1], yet th= e _name_ OP_CSV is much boarder than that. We spent months limiting the num= ber 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 use= case, which is verifying the time/maturity of transaction inputs relative t= o their inclusion in a block.

Suggestions:-

CHECKMATURITYVERIFY
RELATIVELOCKTIMEV= ERIFY
RCHECKLOCKTIMEVERIFY
RCLTV

We could of course softfork additional meaning into OP_CSV= each time we add new sequence number usecases, but that would become obscu= re 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.
=

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



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




--
I like to provide some work at no charge to pr= ove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm th= e webmaster for T= he Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante= .
"He ought to find it more profitable to play by the rules" -= Satoshi Nakamoto
--001a11407c8c65d47605257dd83d--