{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-25\n📝 Original message:Looks like I'm the long dissenting voice here? As the originator of the\nname CHECKSEQUENCEVERIFY, perhaps I can explain why the name was\nappropriately chosen and why the proposed alternatives don't stand up.\n\nFirst, the names are purposefully chosen to illustrate what they do:\n\nWhat does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.\nWhat does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.\n\nSecond, the semantics are not limited to relative lock-time / maturity\nonly. They both leave open ranges with possible, but currently undefined\nfuture consensus-enforced behavior. We don't know what sort of future\nbehavior these values might trigger, but the associated opcodes are generic\nenough to handle them:\n\nCHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even\nthough such constraints have no meaning in Bitcoin.\nCHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,\nwhile checking only 17 of the available 39 bits of both the operand and the\nnSequence. Indeed the most recent semantic change of CSV was justified in\npart because it relaxes all constraints over the values of these bits\nfreeing them for other purposes in transaction validation and/or future\nextensions of the opcode semantics.\n\nThird, single-byte opcode space is limited. There are less than 10 such\nopcodes left. Maybe space won't be so precious in a post-segwitness world,\nbut I don't want to presume that just yet.\n\n\nAs for the alternatives, they capture only the initial use case of\nnSequence. My objection would relax if nSequence were renamed, but I think\nthat would be too disruptive and unnecessary. In any case, the imagined use\ncases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways\nof script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY\nwas a hypothicated opcode that directly checked the minimum age of inputs\nof a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other\nhand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a\nhypothicated opcode that would check a ficticious nRelativeLockTime field,\nwhich does not exist. Again my objection would go away if we renamed\nnSequence, but I actually think the nSequence name is better...\n\nOn Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e BIP68 introduces relative lock-time semantics to part of the nSequence\n\u003e field leaving the majority of bits undefined for other future applications.\n\u003e\n\u003e BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically\n\u003e limited to verifying transaction inputs according to BIP68's relative\n\u003e lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent\n\u003e months limiting the number of bits used in BIP68 so they would be available\n\u003e for future use cases, thus we have acknowledged there will be completely\n\u003e different usecases that take advantage of unused nSequence bits.\n\u003e\n\u003e For this reason I believe the BIP112 should be renamed specifically for\n\u003e it's usecase, which is verifying the time/maturity of transaction inputs\n\u003e relative to their inclusion in a block.\n\u003e\n\u003e Suggestions:-\n\u003e\n\u003e CHECKMATURITYVERIFY\n\u003e RELATIVELOCKTIMEVERIFY\n\u003e RCHECKLOCKTIMEVERIFY\n\u003e RCLTV\n\u003e\n\u003e We could of course softfork additional meaning into OP_CSV each time we\n\u003e add new sequence number usecases, but that would become obscure and\n\u003e confusing. We have already shown there is no shortage of opcodes so it\n\u003e makes no sense to cram everything into one generic opcode.\n\u003e\n\u003e TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase\n\u003e rather than focusing on the bitcoin internals.\n\u003e\n\u003e [1]\n\u003e https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/25ab2f56/attachment-0001.html\u003e"}