From: Matt Corallo <bitcoin-list@bluematt•me>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Date: Mon, 04 May 2015 02:15:47 +0000 [thread overview]
Message-ID: <5546D653.4070404@bluematt.me> (raw)
In-Reply-To: <20150421075912.GA25282@savin.petertodd.org>
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
>
next prev parent reply other threads:[~2015-05-04 2:35 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
2014-10-01 15:01 ` Gavin Andresen
2014-10-02 1:06 ` Peter Todd
2014-10-01 15:29 ` Sergio Lerner
2014-10-01 17:06 ` Peter Todd
2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
2014-10-01 21:04 ` Alan Reiner
2014-10-01 21:34 ` Gavin Andresen
2014-10-02 0:12 ` Peter Todd
2014-10-02 0:05 ` Peter Todd
2014-10-02 0:55 ` Luke Dashjr
2014-10-02 1:09 ` Peter Todd
2014-10-02 15:05 ` Flavien Charlon
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2014-10-03 20:58 ` Mike Hearn
2014-10-03 23:12 ` Jeff Garzik
2014-10-04 0:38 ` Peter Todd
2014-10-04 12:58 ` Mike Hearn
2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
2014-10-08 10:26 ` Wladimir
2014-10-09 3:13 ` Alan Reiner
2014-10-09 6:14 ` Adam Back
2014-10-09 6:28 ` Gregory Maxwell
2014-10-09 6:33 ` Peter Todd
2014-10-09 6:40 ` Gregory Maxwell
2014-10-08 4:07 ` Tom Harding
2014-10-08 10:15 ` Mike Hearn
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
2015-04-26 12:20 ` Jorge Timón
2015-04-27 19:35 ` Peter Todd
2015-04-28 7:44 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo [this message]
2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
2015-05-05 19:19 ` Jorge Timón
2015-05-05 20:38 ` Tier Nolan
2015-05-06 7:37 ` Jorge Timón
2015-05-06 22:09 ` Tier Nolan
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=5546D653.4070404@bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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