{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-26\n📝 Original message:After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK \u003ccondition \u003e VERIFY.\n\nTherefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.\n\nHowever, this name is ridiculously long, so at least some part will require abbreviation.\n\nIn typical script example usage, most sensible seems to be to abbreviate both CLTV and CRLTV.\n\n- Eric\n\nOn November 24, 2015 5:14:55 PM PST, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003eFrom a system developer standpoint, CHECKMATURITYVERIFY ties together \n\u003ethe semantics of this opcode with another existing feature in the\n\u003esystem \n\u003e(coinbase maturity).\n\u003e\n\u003eHOWEVER...\n\u003e\n\u003efrom an application developer standpoint, I think the concept of a \n\u003etimelock is more relevant. Maturity is a concept that was introduced\n\u003efor \n\u003ethe sake of reducing the disruptive impact of reorgs. Miners would \n\u003eprefer to be able to spend the coins immediately, but instead they are \n\u003eforced to wait due to inherent limitations of the system. Timelocks, on\n\u003e\n\u003ethe other hand, are typically used to control when funds can be moved. \n\u003eIn these use cases, one or more of the parties involved explicitly want\n\u003e\n\u003ethere to be a delay even if there were an idealized situation in which \n\u003econsensus is always reached instantaneously and there were never any \n\u003ereorgs.\n\u003e\n\u003eMoreover, since we already have CLTV, adding RCLTV or some variant \n\u003ethereof makes the relationship between the two more explicit.\n\u003e\n\u003eSo my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.\n\u003e\n\u003eAs for whether to explicitly use CHECK_..._VERIFY, consider that with \n\u003esegregated witness it will be possible to add opcodes that can push \n\u003evalues onto the stack (rather than just hard failing or NOP), so\n\u003ethere's \n\u003esomething to be said for naming consistency.\n\u003e\n\u003e- Eric\n\u003e\n\u003e\n\u003e\n\u003e------ Original Message ------\n\u003eFrom: \"Jorge Timón\" \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/24/2015 4:31:55 AM\n\u003eSubject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY \n\u003e(BIP112)\n\u003e\n\u003e\u003eI agree, I believe the first name that an op with equivalent \n\u003e\u003efunctionality had was simply op_maturity.\n\u003e\u003eAt least I remember we discussed such an opcode when discussing pegged\n\u003e\n\u003e\u003esidechains' design.\n\u003e\u003e\n\u003e\u003eI kind of dislike the check_x_verify naming pattern. We want all new \n\u003e\u003eoperands to return if whatever they're checking/verifying fails, fine.\n\u003e\n\u003e\u003eDo we have to repeat this redundant naming pattern forever due to that\n\u003e\n\u003e\u003ediscovery?\n\u003e\u003eI hope not, but if that's the case my vote is for CMV.\n\u003e\u003eAs said before, I believe the documentation and code comments can \n\u003e\u003ebecome much more clear with this change.\n\u003e\u003e\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151126/6326f2b7/attachment.html\u003e"}