From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xu8la-0000Y5-RZ for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 23:46:30 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.174 as permitted sender) client-ip=209.85.213.174; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f174.google.com; Received: from mail-ig0-f174.google.com ([209.85.213.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xu8lY-00040C-Sd for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 23:46:30 +0000 Received: by mail-ig0-f174.google.com with SMTP id hn15so9130754igb.13 for ; Thu, 27 Nov 2014 15:46:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.74.193 with SMTP id yx1mr13829345icb.62.1417131983533; Thu, 27 Nov 2014 15:46:23 -0800 (PST) Received: by 10.107.18.65 with HTTP; Thu, 27 Nov 2014 15:46:23 -0800 (PST) In-Reply-To: <63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com> References: <63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com> Date: Thu, 27 Nov 2014 23:46:23 +0000 Message-ID: From: Gregory Maxwell To: Richard Moore Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Xu8lY-00040C-Sd Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:46:30 -0000 On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore 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 {) 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 OP_CHECKLOCKTIMEVERIFY OP_ELSE 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.