{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-26\n📝 Original message: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.\n\nOn November 25, 2015 6:41:03 PM EST, Eric Lombrozo via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eAs I said in an earlier post, a systems developer and an application \n\u003edeveloper have very different perspectives on this. From the former's \n\u003eperspective, it is entirely sensible to name things based on basic \n\u003efeatures of the system's design (i.e. a field in the txin or tx that \n\u003egets checked) - but from an app developer's perspective, what matters\n\u003eis \n\u003ehow they will use a particular feature in an actual app.\n\u003e\n\u003eI think that part of what systems developers should strive to do is to \n\u003eabstract out the inner minutiae of the system's guts and expose to app \n\u003edevelopers the clearest interface with which to develop apps. This is \n\u003eeven more the case when the details of the inner workings are\n\u003ecompletely \n\u003eirrelevant to the application logic and there's no real gains to be had\n\u003e\n\u003efrom attempting to optimize for the inner workings when designing an \n\u003eapplication.\n\u003e\n\u003eFrom an app developer's perspective, I think it is pretty blatantly \n\u003eclear that relative timelock is *the* critical exposed functionality \n\u003eintended here. Now, one could argue that the satoshi script is still a \n\u003esystems level component of the system...but with the advent of overlay \n\u003eprotocols such as payment channels and the Lightning Network, it is \n\u003eclear that we now require a new abstraction layer for reasoning about \n\u003ethe higher level logic of the system that doesn't burden the protocol \n\u003edesigner with having to know the intimate and esoteric details of the \n\u003elower system levels. Of course, many of those who work on these higher \n\u003elevel protocols will also be experts in the underlying system design. \n\u003eHowever, it greatly increases the learning curve and can easily \n\u003efrustrate people looking to work on these ideas...and ultimately, \n\u003eknowing the inner details of how the nSequence field is structured and \n\u003ewhat the bits actually mean is irrelevant to someone trying to design \n\u003escripts for such applications.\n\u003e\n\u003eWe've already deployed another opcode, CHECKLOCKTIMEVERIFY, which does \n\u003erefer to the field name. However, in this particular situation, the \n\u003efield name reflects *far* more closely what the app developer actually \n\u003ecares about than nSequence, which to the app developer might as well be\n\u003e\n\u003ecalled foo. As such, I stick with my original vote - we should call the\n\u003e\n\u003eopcode RCHECKLOCKTIMEVERIFY, which has the advantage of communicating \n\u003efairly directly to developers and protocol designers the semantics they\n\u003e\n\u003eactually care about and also makes clear the relationship between \n\u003eabsolute and relative timelock...that's to say, the ability for the \n\u003escript designer to lock specific coins until either a specific moment\n\u003ein \n\u003etime or until a certain delay has passed since the coin output was \n\u003ecreated (added to blockchain).\n\u003e\n\u003eLet's face it - the entire motivation behind BIP68/BIP112 is relative \n\u003etimelock. Explicitly calling the opcode RCHECKLOCKTIMEVERIFY will make \n\u003elife easier for everyone and will help sell the idea and help it gain \n\u003egreater acceptance more quickly; while stubbornly adhering to an \n\u003eesoteric detail that is only there for historical reasons will only \n\u003econtinue to delay the idea's acceptance and adoptance.\n\u003e\n\u003e- Eric\n\u003e\n\u003e------ Original Message ------\n\u003eFrom: \"Mark Friedenbach via bitcoin-dev\" \n\u003e\u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003eTo: \"Btc Drak\" \u003cbtcdrak at gmail.com\u003e\n\u003eCc: \"Bitcoin Dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003eSent: 11/25/2015 3:05:50 PM\n\u003eSubject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY \n\u003e(BIP112)\n\u003e\n\u003e\u003eLooks like I'm the long dissenting voice here? As the originator of\n\u003ethe \n\u003e\u003ename CHECKSEQUENCEVERIFY, perhaps I can explain why the name was \n\u003e\u003eappropriately chosen and why the proposed alternatives don't stand up.\n\u003e\u003e\n\u003e\u003eFirst, the names are purposefully chosen to illustrate what they do:\n\u003e\u003e\n\u003e\u003eWhat does CHECKLOCKTIMEVERIFY do? It verifies the range of \n\u003e\u003etx.nLockTime.\n\u003e\u003eWhat does CHECKSEQUENCEVERIFY do? It verifies the range of \n\u003e\u003etxin.nSequence.\n\u003e\u003e\n\u003e\u003eSecond, the semantics are not limited to relative lock-time / maturity\n\u003e\n\u003e\u003eonly. They both leave open ranges with possible, but currently \n\u003e\u003eundefined future consensus-enforced behavior. We don't know what sort \n\u003e\u003eof future behavior these values might trigger, but the associated \n\u003e\u003eopcodes are generic enough to handle them:\n\u003e\u003e\n\u003e\u003eCHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even\n\u003e\n\u003e\u003ethough such constraints have no meaning in Bitcoin.\n\u003e\u003eCHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push \n\u003e\u003eoperand, while checking only 17 of the available 39 bits of both the \n\u003e\u003eoperand and the nSequence. Indeed the most recent semantic change of \n\u003e\u003eCSV was justified in part because it relaxes all constraints over the \n\u003e\u003evalues of these bits freeing them for other purposes in transaction \n\u003e\u003evalidation and/or future extensions of the opcode semantics.\n\u003e\u003e\n\u003e\u003eThird, single-byte opcode space is limited. There are less than 10\n\u003esuch \n\u003e\u003eopcodes left. Maybe space won't be so precious in a post-segwitness \n\u003e\u003eworld, but I don't want to presume that just yet.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003eAs for the alternatives, they capture only the initial use case of \n\u003e\u003enSequence. My objection would relax if nSequence were renamed, but I \n\u003e\u003ethink that would be too disruptive and unnecessary. In any case, the \n\u003e\u003eimagined use cases for CHECKSEQUENCEVERIFY has to do with sequencing \n\u003e\u003eexecution pathways of script, so it's not a stretch in meaning. \n\u003e\u003ePreviously CHECKMATURITYVERIFY was a hypothicated opcode that directly\n\u003e\n\u003e\u003echecked the minimum age of inputs of a transaction. The indirect\n\u003enaming \n\u003e\u003eof CHECKSEQUENCEVERIFY on the other hand is due to its indirect \n\u003e\u003ebehavior. RELATIVELOCKTIMEVERIFY was also a hypothicated opcode that \n\u003e\u003ewould check a ficticious nRelativeLockTime field, which does not\n\u003eexist. \n\u003e\u003eAgain my objection would go away if we renamed nSequence, but I \n\u003e\u003eactually think the nSequence name is better...\n\u003e\u003e\n\u003e\u003eOn Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev \n\u003e\u003e\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003eBIP68 introduces relative lock-time semantics to part of the\n\u003enSequence \n\u003e\u003e\u003efield leaving the majority of bits undefined for other future \n\u003e\u003e\u003eapplications.\n\u003e\u003e\u003e\n\u003e\u003e\u003eBIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is \n\u003e\u003e\u003especifically limited to verifying transaction inputs according to \n\u003e\u003e\u003eBIP68's relative lock-time[1], yet the _name_ OP_CSV is much boarder \n\u003e\u003e\u003ethan that. We spent months limiting the number of bits used in BIP68 \n\u003e\u003e\u003eso they would be available for future use cases, thus we have \n\u003e\u003e\u003eacknowledged there will be completely different usecases that take \n\u003e\u003e\u003eadvantage of unused nSequence bits.\n\u003e\u003e\u003e\n\u003e\u003e\u003eFor this reason I believe the BIP112 should be renamed specifically \n\u003e\u003e\u003efor it's usecase, which is verifying the time/maturity of transaction\n\u003e\n\u003e\u003e\u003einputs relative to their inclusion in a block.\n\u003e\u003e\u003e\n\u003e\u003e\u003eSuggestions:-\n\u003e\u003e\u003e\n\u003e\u003e\u003eCHECKMATURITYVERIFY\n\u003e\u003e\u003eRELATIVELOCKTIMEVERIFY\n\u003e\u003e\u003eRCHECKLOCKTIMEVERIFY\n\u003e\u003e\u003eRCLTV\n\u003e\u003e\u003e\n\u003e\u003e\u003eWe could of course softfork additional meaning into OP_CSV each time \n\u003e\u003e\u003ewe add new sequence number usecases, but that would become obscure\n\u003eand \n\u003e\u003e\u003econfusing. We have already shown there is no shortage of opcodes so\n\u003eit \n\u003e\u003e\u003emakes no sense to cram everything into one generic opcode.\n\u003e\u003e\u003e\n\u003e\u003e\u003eTL;DR: let's give BIP112 opcode a name that reflects it's actual \n\u003e\u003e\u003eusecase rather than focusing on the bitcoin internals.\n\u003e\u003e\u003e\n\u003e\u003e\u003e[1] \n\u003e\u003e\u003ehttps://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223\n\u003e\u003e\u003e\n\u003e\u003e\u003e_______________________________________________\n\u003e\u003e\u003ebitcoin-dev mailing list\n\u003e\u003e\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151126/9a401bd9/attachment-0001.html\u003e"}