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



  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.me \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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