diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-04-26 13:35:33 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-04-26 11:35:42 +0000 |
| commit | 585691f6a827b1ee54b8b83d3bc58cc28fb9a5ff (patch) | |
| tree | a8986f83f56d518e55df5dcf448a7137da4a78a3 | |
| parent | d694d25b86ad746fd649e0bad32fbec84c5f60c3 (diff) | |
| download | pi-bitcoindev-585691f6a827b1ee54b8b83d3bc58cc28fb9a5ff.tar.gz pi-bitcoindev-585691f6a827b1ee54b8b83d3bc58cc28fb9a5ff.zip | |
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
| -rw-r--r-- | c2/d1ee6848720ca5233eee4741653a5e5216a18c | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/c2/d1ee6848720ca5233eee4741653a5e5216a18c b/c2/d1ee6848720ca5233eee4741653a5e5216a18c new file mode 100644 index 000000000..b7e8dd9e5 --- /dev/null +++ b/c2/d1ee6848720ca5233eee4741653a5e5216a18c @@ -0,0 +1,207 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jtimon@jtimon.cc>) id 1YmKqc-0000XG-9j + for bitcoin-development@lists.sourceforge.net; + Sun, 26 Apr 2015 11:35:42 +0000 +Received: from mail-wi0-f177.google.com ([209.85.212.177]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YmKqZ-0005HR-UU + for bitcoin-development@lists.sourceforge.net; + Sun, 26 Apr 2015 11:35:42 +0000 +Received: by wicmx19 with SMTP id mx19so64298920wic.1 + for <bitcoin-development@lists.sourceforge.net>; + Sun, 26 Apr 2015 04:35:33 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=VsvLhQXYTuuvfJ4kA0hwry7nU2B+jPALJoHwB/fSMvE=; + b=artD8JYAtYAMmhvbRSdLYMTQ6txFLmeYqddq/YTXlhkjZYmtKD5YeuvY4ZYkTxWKbi + dkime2vQdRNs5XUz6ZsHL+wC++Y6mAl/LNvjDFuok68cfx2Y1lKmaqciBygexcDt3jcx + Bv9izdbu+n7NNXzCmhQUwVUYmHeSqexMAokpjawMkv+hnEYVhdBQjWlpnFtGxRxvWJjR + m96yjjzAAI9pHTrGKSgWGlpVlPzeWwFesW6IyJlXtssDbTk0nf3WanvX7652QqASR205 + KNRaiDZpBTu5bslFTI1uPXou30gT54xMa/I8+0d1UTWtfS3OYiQbrk94jviNPcnvNtVF + agfw== +X-Gm-Message-State: ALoCoQnehoGBvROEd1Mwy896U31Nt7YQ/Jx3+9lH6ULiL7j1kRloetmdKIhYuvk2pT9tmEh73cS7 +MIME-Version: 1.0 +X-Received: by 10.180.37.73 with SMTP id w9mr12031409wij.7.1430048133662; Sun, + 26 Apr 2015 04:35:33 -0700 (PDT) +Received: by 10.194.124.2 with HTTP; Sun, 26 Apr 2015 04:35:33 -0700 (PDT) +In-Reply-To: <20150421075912.GA25282@savin.petertodd.org> +References: <20141001130826.GM28710@savin.petertodd.org> + <55075795.20904@bluematt.me> + <20150421075912.GA25282@savin.petertodd.org> +Date: Sun, 26 Apr 2015 13:35:33 +0200 +Message-ID: <CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Peter Todd <pete@petertodd.org> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1YmKqZ-0005HR-UU +Cc: Bitcoin Dev <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: Sun, 26 Apr 2015 11:35:42 -0000 + +On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd <pete@petertodd.org> wrote: +> 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. + +Yes, can we call this one OP_MATURITY to distinguish it from RCLTV? + +> 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. + +Mhmm, interesting. + +> 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. + +I'm totally fine with changing the interface to: + + int bitcoinconsensus_verify_script(const unsigned char +*scriptPubKey, unsigned int scriptPubKeyLen, + const unsigned char *txTo + , unsigned int txToLen, unsigned nHeight, + unsigned int nIn, unsigned int +flags, bitcoinconsensus_error* err); + +I prefer op_maturity over RCLTV and there are also gains for absolute +CLTV as you explain later. +When you validate the script inputs of a transaction you already have +a height, either the real final nHeight in ConnectBlock and the miner, +or nSpendHeight in AcceptToMemoryPool. +The costs are meaningless in my opinion, specially when we will +already have to change the interface to add libsecp256k1's context. + +I'm infinitely more worried about the other assumption that the 3 +solutions are already making. +Changing to + + int bitcoinconsensus_verify_script(const unsigned char +*scriptPubKey, unsigned int scriptPubKeyLen, + const unsigned char *txTo + , unsigned int txToLen, const CCoinsViewCache& inputs, + unsigned int nIn, unsigned int +flags, bitcoinconsensus_error* err); + +Is simply not possible because CCoinsViewCache is a C++. +You could solve it in a similar way in which you could solve that +dependency for VerifyTransaction. +For example: + +typedef const CTxOut& (*TxOutputGetter)(const uint256& txid, uint32_t n); + + int bitcoinconsensus_verify_script(const unsigned char +*scriptPubKey, unsigned int scriptPubKeyLen, + const unsigned char *txTo + , unsigned int txToLen, TxOutputGetter utxoGetter, + unsigned int nIn, unsigned int +flags, bitcoinconsensus_error* err); + +Of course, this is assuming that CTxOut becomes a C struct instead of +a C++ class and little things like that. +In terms of code encapsulation, this is still 100 times uglier than +adding the nHeight so if we're doing it, yes, please, let's do both. + +There's another possibility that could keep the utxo out of Script verification: + +class CTxIn +{ +public: + COutPoint prevout; + CScript scriptSig; + uint32_t nSequence; +} + +could turn into: + +class CTxIn +{ +public: + COutPoint prevout; + CScript scriptSig; + uint32_t nHeight; +} + +And a new softfork rule could enforce that all new CTxIn set nHeight +to the correct height in which its corresponding prevout got into the +chain. +That would remove the need for the TxOutputGetter param in +bitcoinconsensus_verify_script, but unfortunately it is not reorg safe +(apart from other ugly implementation details). + +So, in summary, I think the new interface has to be something along these lines: + + int bitcoinconsensus_verify_script(const unsigned char +*scriptPubKey, unsigned int scriptPubKeyLen, + const unsigned char *txTo, +unsigned int nIn, + unsigned int txToLen, +TxOutputGetter utxoGetter, unsigned nHeight, secp256k1_context_t *ctx + unsigned int flags, +bitcoinconsensus_error* err); + +> 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 + +I'm totally fine not supporting time-based locks for the new operators. +Removing them from the regular nLockTime could be more complicated but +I wouldn't mind either. +Every time I think of a contract or protocol that involves time, I do +it in terms of block heights. +I would prefer to change all my clocks to work in blocks instead of +minutes over changing nHeights for timestamps in any of those +contracts. + +> -- +> 'peter'[:-1]@petertodd.org +> 0000000000000000015e09479548c5b63b99a62d31b019e6479f195bf0cbd935 +> +> ------------------------------------------------------------------------------ +> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT +> Develop your own process in accordance with the BPMN 2 standard +> Learn Process modeling best practices with Bonita BPM through live exercises +> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ +> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + + |