Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bitcoin-list@bluematt.me>) id 1Yp6EQ-0005zk-9v
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 May 2015 02:35:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 192.241.179.72 as permitted sender)
	client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
	helo=mail.bluematt.me; 
Received: from mail.bluematt.me ([192.241.179.72])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Yp6EO-0004iS-Vh
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 May 2015 02:35:42 +0000
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
	by mail.bluematt.me (Postfix) with ESMTPSA id 6EAF4408BA;
	Mon,  4 May 2015 02:15:48 +0000 (UTC)
Message-ID: <5546D653.4070404@bluematt.me>
Date: Mon, 04 May 2015 02:15:47 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
In-Reply-To: <20150421075912.GA25282@savin.petertodd.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.5 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1Yp6EO-0004iS-Vh
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
 proposal)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2015 02:35:42 -0000



On 04/21/15 07:59, Peter Todd wrote:
> On Mon, Mar 16, 2015 at 10:22:13PM +0000, Matt Corallo wrote:
>> In building some CLTV-based contracts, it is often also useful to have a
>> method of requiring, instead of locktime-is-at-least-N,
>> locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
>> an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
>> stack element, adds the height of the output being spent and then has
>> identical semantics to CLTV.
> 
> Depending on what you mean by "identical" this isn't actually reorg
> safe. For instance consider this implementation:
> 
>     nLockTime = stack[-1] + prevout.nHeight
>     if (nLockTime > txTo.nLockTime):
>         return False
> 
> Used with this scriptPubKey:
> 
>     10 RCLTV DROP <pubkey> CHECKSIG
> 
> If I create that output in tx1 which is mined at height 42 I can spend
> it in a tx2 at height > 42+10 by setting tx2's nLockTime to >42+10, for
> instance 53. However if a reorg happens and tx1 ends up at height 43
> after the reorg I'm stuck - tx2's nLockTime is set at 42.
> 
> Thus RCTLV is only reorg safe if the height is compared against the
> actual block height of the block containing the spending transaction,
> not the spending transaction's nLockTime.

Yes, as discussed on IRC months ago when the first email was sent, the
assumption is that you would require N be at least 100. That way you are
reorg safe up to the same limit as coinbase transactions, which are also
only reorg safe in the case of no 100-block reorgs. Its not ideal in
some contracts, but keeping the no-second-nLockTime-equivalent property
is worth it IMO, and its still incredibly useful in many contracts.

>> A slightly different API (and different name) was described by maaku at
>> http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
>> which does a better job of saving softfork-available opcode space.
>>
>> There are two major drawbacks to adding such an operation, however.
>>
>> 1) More transaction information is exposed inside the script (prior to
>> CLTV we only had the sigchecking operation exposed, with a CLTV and
>> RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
>>
>> 2) Bitcoin Core's mempool invariant of "all transactions in the mempool
>> could be thrown into one overside block and aside from block size, it
>> would be valid" becomes harder to enforce. Currently, during reorgs,
>> coinbase spends need checked (specifically, anything spending THE
>> coinbase 100 blocks ago needs checked) and locktime transactions need
>> checked. With such a new operation, any script which used this new
>> opcode during its execution would need to be re-evaluated during reorgs.
> 
> Yup, definitely kinda ugly.
> 
> If the above style of RCTLV was used, one possibility might be to make
> the relative locktime difference be required to be at least 100 blocks,
> same as the coinbase maturity, and just accept that it's probably not
> going to cause any problems, but could in an extremely big reorg. But
> re-orgs that big might be big enough that we're screwed anyway...
> 
> With the 100 block rule, during a sufficiently large reorg that
> coinbases become unavailble, simply disconnect entire blocks - all
> txouts created by them.
> 
>> I think both of these requirements are reasonable and not particularly
>> cumbersome, and the value of such an operation is quite nice for some
>> protocols (including settings setting up a contest interval in a
>> sidechain data validation operation).
> 
> So to be clear, right now the minimal interface to script execution is
> simply:
> 
>     int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, unsigned int scriptPubKeyLen,
>                                        const unsigned char *txTo        , unsigned int txToLen,
>                                        unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err);
> 
> Where scriptPubKey is derived from the unspent coin in the UTXO set and
> txTo is the transaction containing the script that is being executed.
> The UTXO set itself currently contains CCoins entries, one for each
> transaction with unspent outputs, which basically contain:
> 
>     nVersion - tx nVersion
>     nHeight  - Height of the block the transaction is contained in.
>     vout     - Unspent CTxOut's of the transaction.
> 
> The block nTime isn't directly available through the UTXO set, although
> it can be found in the block headers. This does require nodes to have
> the block headers, but at 4MB/year growth it's reasonable to assume the
> UTXO set will grow faster.
> 
> Script execution does not have direct access to the current block
> height/block time, however it does have indirect access via nLockTime.
> 
> Thus we have a few possibilities:
> 
> 1) RCLTV against nLockTime
> 
> Needs a minimum age > COINBASE_MATURITY to be safe.
> 
> 
> 2) RCLTV against current block height/time
> 
> Completely reorg safe.
> 
> 
> 3) GET_TXOUT_HEIGHT/TIME <diff> ADD CLTV
> 
> To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age <
> COINBASE_MATURITY. This can be implemented by comparing against
> nLockTime.
> 
> 
> All three possibilities require us to make information about the
> prevout's height/time available to VerifyScript(). The only question is
> if we want VerifyScript() to also take the current block height/time - I
> see no reason why it can't. As for the mempool, keeping track of what
> transactions made use of these opcodes so they can be reevaluated if
> their prevouts are re-organised seems fine to me.
> 
> 
> Absolute CLTV
> =============
> 
> If we are going to make the block height/time available to
> VerifyScript() to implement RCLTV, should absolute CLTV should continue
> to have the proposed behavior of checking against nLockTime? If we go
> with RCLTV against current block height/time, I'm going to vote no,
> because doing so needlessly limits it to only being able to compare
> against a block height or a block time in a single transaction.
> Similarly it can complicate multi-party signatures in some
> circumstances, as all parties must agree on a common nLockTime.
> 
> 
> Time-based locks
> ================
> 
> Do we want to support them at all? May cause incentive issues with
> mining, see #bitcoin-wizards discussion, Jul 17th 2013:
> 
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-17.log
>