📅 Original date posted:2015-11-24
📝 Original message:>From a system developer standpoint, CHECKMATURITYVERIFY ties together
the semantics of this opcode with another existing feature in the system
(coinbase maturity).
HOWEVER...
from an application developer standpoint, I think the concept of a
timelock is more relevant. Maturity is a concept that was introduced for
the sake of reducing the disruptive impact of reorgs. Miners would
prefer to be able to spend the coins immediately, but instead they are
forced to wait due to inherent limitations of the system. Timelocks, on
the other hand, are typically used to control when funds can be moved.
In these use cases, one or more of the parties involved explicitly want
there to be a delay even if there were an idealized situation in which
consensus is always reached instantaneously and there were never any
reorgs.
Moreover, since we already have CLTV, adding RCLTV or some variant
thereof makes the relationship between the two more explicit.
So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.
As for whether to explicitly use CHECK_..._VERIFY, consider that with
segregated witness it will be possible to add opcodes that can push
values onto the stack (rather than just hard failing or NOP), so there's
something to be said for naming consistency.
- Eric
------ Original Message ------
From: "Jorge Timón" <bitcoin-dev at lists.linuxfoundation.org>
To: "Btc Drak" <btcdrak at gmail.com>
Cc: "Bitcoin Dev" <bitcoin-dev at lists.linuxfoundation.org>
Sent: 11/24/2015 4:31:55 AM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY
(BIP112)
>I agree, I believe the first name that an op with equivalent
>functionality had was simply op_maturity.
>At least I remember we discussed such an opcode when discussing pegged
>sidechains' design.
>
>I kind of dislike the check_x_verify naming pattern. We want all new
>operands to return if whatever they're checking/verifying fails, fine.
>Do we have to repeat this redundant naming pattern forever due to that
>discovery?
>I hope not, but if that's the case my vote is for CMV.
>As said before, I believe the documentation and code comments can
>become much more clear with this change.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/f2bded13/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:45:07
in reply to nevent1q…ax44
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:45:07Event JSON
{
"id": "2680b661e1159ef63e8631259c320c82d7c12785d72b0c6a9a6e0035ef9f7bc0",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159907,
"kind": 1,
"tags": [
[
"e",
"65176681f906c98989ff4af1f66f139d152a7b5de4ac302f54d83aa23ee2fe52",
"",
"root"
],
[
"e",
"4c64d9450cb13cd93812d0e9cd035eab796a34d9cf979842240369bff1e7f355",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-11-24\n📝 Original message:\u003eFrom a system developer standpoint, CHECKMATURITYVERIFY ties together \nthe semantics of this opcode with another existing feature in the system \n(coinbase maturity).\n\nHOWEVER...\n\nfrom an application developer standpoint, I think the concept of a \ntimelock is more relevant. Maturity is a concept that was introduced for \nthe sake of reducing the disruptive impact of reorgs. Miners would \nprefer to be able to spend the coins immediately, but instead they are \nforced to wait due to inherent limitations of the system. Timelocks, on \nthe other hand, are typically used to control when funds can be moved. \nIn these use cases, one or more of the parties involved explicitly want \nthere to be a delay even if there were an idealized situation in which \nconsensus is always reached instantaneously and there were never any \nreorgs.\n\nMoreover, since we already have CLTV, adding RCLTV or some variant \nthereof makes the relationship between the two more explicit.\n\nSo my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.\n\nAs for whether to explicitly use CHECK_..._VERIFY, consider that with \nsegregated witness it will be possible to add opcodes that can push \nvalues onto the stack (rather than just hard failing or NOP), so there's \nsomething to be said for naming consistency.\n\n- Eric\n\n\n\n------ Original Message ------\nFrom: \"Jorge Timón\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nTo: \"Btc Drak\" \u003cbtcdrak at gmail.com\u003e\nCc: \"Bitcoin Dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: 11/24/2015 4:31:55 AM\nSubject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY \n(BIP112)\n\n\u003eI agree, I believe the first name that an op with equivalent \n\u003efunctionality had was simply op_maturity.\n\u003eAt least I remember we discussed such an opcode when discussing pegged \n\u003esidechains' design.\n\u003e\n\u003eI kind of dislike the check_x_verify naming pattern. We want all new \n\u003eoperands to return if whatever they're checking/verifying fails, fine. \n\u003eDo we have to repeat this redundant naming pattern forever due to that \n\u003ediscovery?\n\u003eI hope not, but if that's the case my vote is for CMV.\n\u003eAs said before, I believe the documentation and code comments can \n\u003ebecome much more clear with this change.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151125/f2bded13/attachment.html\u003e",
"sig": "e36b071de56fd03abcea06fe00f002485b9867756eae75a650224f56dcafd42741a972cf1da3b30598273a18e376faf7ecdfcb8d9d816c09122b59a39ad884b0"
}