From: Gregory Maxwell <gmaxwell@gmail•com>
To: Richard Moore <me@ricmoo•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
Date: Thu, 27 Nov 2014 23:46:23 +0000 [thread overview]
Message-ID: <CAAS2fgSr7-s-Bg-6Fjs1=dg0WR4JZfWbx2hnSyU4iXRNKHma4Q@mail.gmail.com> (raw)
In-Reply-To: <63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com>
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore <me@ricmoo•com> wrote:
> 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?
Updating the stack is not soft-fork compatible and any use would
immediately fork the network.
A invertible test is also not soft-fork compatible e.g. someone writes
a script that does {<new thing>) OP_NOT, in other words "the test
must fail", then the network would fork because older nodes would see
it as passing (which was the required criteria for non-forking the
network in the non-inverted caes).
You can happily get non-nullable true/false behaviour without these
risks by having the VERIFY test inside a branch and having the signer
provide its falseness as an input to the branch. This is explained in
the BIP.
E.g. OP_IF <limit> OP_CHECKLOCKTIMEVERIFY OP_ELSE <what you'd do if it
doesn't pass> OP_END
A useful an powerful mental model is that SCRIPT is not running a
program, but instead the signer is proving to the network that they
know inputs that make the program return true.
(In practise we verify this by actually doing some execution, though
this isn't technically necessary it's the simplest thing to implement
although it is inefficient... but even in this simple model keeping in
mind that we're VERIFYING not executing in the network opens our eyes
to transformations like the IF bracketing of a VERIFY opcode.)
> That way someone could include multiple OP_CHECKLOCKTIME conditions in a
> single script.
They can do this, with the above approach.
> 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
Then the scripts validity isn't a pure function of the the
transaction, and once valid transactions could become invalid while in
the mempool. This breaks existing invariants and would make the coins
potentially less fungible because they wouldn't be reorg safe. That
locktime validity is basically monotonic is a useful intentional
property. :)
The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more clarification to make
this more clear.
next prev parent reply other threads:[~2014-11-27 23:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 22:56 Richard Moore
2014-11-27 23:46 ` Gregory Maxwell [this message]
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='CAAS2fgSr7-s-Bg-6Fjs1=dg0WR4JZfWbx2hnSyU4iXRNKHma4Q@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=me@ricmoo$(echo .)com \
/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