From: Richard Moore <me@ricmoo.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
Date: Thu, 27 Nov 2014 17:56:54 -0500 [thread overview]
Message-ID: <63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought it might make more sense to instead have a OP_CHECKLOCKTIME which would simply push an OP_TRUE or OP_FALSE onto the stack?
That way someone could include multiple OP_CHECKLOCKTIME conditions in a single script. It is trivial to always emulate OP_CHECKLOCKTIMEVERIFY by using a OP_CHECKLOCKTIME OP_VERIFY sequence.
As a second question, would it possibly make more sense to, rather than relying on the nLockTime in a transaction, allow an opcode that would use similar semantics, but against an item in the stack? Then you could essentially include multiple nLockTimes in a single script and make arbitrarily interesting (complicated?) scripts based on block height and/or block timestamp.
The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using
nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY
Just something that came to mind while reading about OP_CHECKLOCKTIMEVERIFY.
Thanks,
RicMoo
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com <mailto:ricmoo@geneticmistakes.com>
www: http://GeneticMistakes.com <http://geneticmistakes.com/>
[-- Attachment #2: Type: text/html, Size: 2336 bytes --]
next reply other threads:[~2014-11-27 23:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 22:56 Richard Moore [this message]
2014-11-27 23:46 ` [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry Gregory Maxwell
2014-11-28 3:18 ` Peter Todd
2014-11-28 11:45 ` Flavien Charlon
2014-11-28 12:03 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com \
--to=me@ricmoo.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox