public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

             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 ` 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$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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