Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón jti...@jtimon.cc wrote: This gives you less flexibility and I don't think it's necessary. Please let's try to avoid this if it's possible. It is just a switch that turns on and off the new mode. In retrospect, it would be better to just up the transaction version. In transactions from v2 onwards, the sequence field means height. That means legacy transactions would be spendable. This is a pure soft-fork. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
I think that should be greater than in the comparison? You want it to fail
if the the height of the UTXO plus the sequence number is greater than the
spending block's height.
There should be an exception for final inputs. Otherwise, they will count
as relative locktime of 0x. Is this check handled elsewhere?
if (!tx.vin[i].IsFinal() nSpendHeight coins-nHeight +
tx.vin[i].nSequence)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
Is the intention to let the script check the sequence number?
number OP_RELATIVELOCKTIMEVERIFY
would check if number is less than or equal to the sequence number.
It does make sequence mean something completely different from before.
Invalidating previously valid transactions has the potential to reduce
confidence in the currency.
A workaround would be to have a way to enable it in the sigScript by
extending Peter Todd's suggestion in the other email chain.
1 OP_NOP2 means OP_CHECKLOCKTIMEVERIFY (absolute)
2 OP_NOP2 means OP_RELATIVECHECKLOCKTIMEVERIFY
3 OP_NOP2 means OP_SEQUENCE_AS_RELATIVE_HEIGHT
OP_SEQUENCE_AS_RELATIVE_HEIGHT would cause the script to fail unless it was
the first opcode in the script. It acts as a flag to enable using the
sequence number as for relative block height.
This can be achieved using a simple pattern match.
bool CScript::IsSequenceAsRelativeHeight() const
{
// Extra-fast test for pay-to-script-hash CScripts:
return (this-size() = 4
this-at(0) == OP_PUSHDATA1
this-at(1) == 1
this-at(2) == 0xFF
this-at(3) == OP_NOP2);
}
if (!tx.vin[i].IsFinal()
tx.vin[i].scriptSig.IsSequenceAsRelativeHeight() nSpendHeight
coins-nHeight + tx.vin[i].nSequence)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
On Mon, May 4, 2015 at 12:24 PM, Jorge Timón jti...@jtimon.cc wrote:
for (unsigned int i = 0; i tx.vin.size(); i++) {
// ...
if (coins-nHeight + tx.vin[i].nSequence nSpendHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
// ...
}
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
What I was describing was an attempt to fix a similar proposal by Mark
Friedenbach, but it didn't needed fixing: I was simply
misunderstanding it.
Mark's RCLTV is completely reorg safe, so there's no need for the 100
block restriction. It also keeps the script validation independent
from the utxo.
Here's is how it works:
The operator takes a relative_height parameter and it checks that the
nSequence of the input is lower than that parameter.
Additionally, a new check at the transaction level:
for (unsigned int i = 0; i tx.vin.size(); i++) {
// ...
if (coins-nHeight + tx.vin[i].nSequence nSpendHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
// ...
}
Well, this is assuming that we're only using it with heights and not timestamps.
Mark, feel free to elaborate further.
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On 04/21/15 07:59, Peter Todd wrote: On Mon, Mar 16, 2015 at 10:22:13PM +, 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
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Even if it's new and has not received any feedback, I think my solution to op_maturity is quite clean. But anyway, yes, the non-relative cltv is much simpler in design and doesn't have to wait for the other. On the other hand, I would upgrade it to absolute cltv like you suggested and take the current height as a parameter to verifyScript instead of using the nLockTime as reference. If we know we're going to use it for rcltv/op_maturity, better put add soon rather than later, specially if that will give us a more powerful cltv. If we don't want that height param, we can leave it out of for op_maturity too, but that's the wingle decision about rcltv/maturity that affects cltv so better solve that first. On Apr 27, 2015 9:35 PM, Peter Todd p...@petertodd.org wrote: On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: 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). Wait, wait, this can be made reorg-safe and more backards compatible. The new validation rule at the tx validation level (currently in main::CheckInputs()) would be snip So, seems to me that RCLTV opens up a whole rats nest of design decisions and compromises that CLTV doesn't. Yet CLTV itself is a big step forward, it's been implemented on Viacoin for the past few months with no issues found, and has an extremely simple and easy to audit implementation. I think I'm going to argue we implement it as-is in a soft-fork. Pieter Wuille's been working on a new way to handle soft-fork upgrades in the block nVersion field, so this would be a good opportunity to add something simple and well tested, and also make sure the new nVersion soft-fork mechanism works. Equally, doing both at the same time ensures we don't burn yet another version bit. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: 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). Wait, wait, this can be made reorg-safe and more backards compatible. The new validation rule at the tx validation level (currently in main::CheckInputs()) would be snip So, seems to me that RCLTV opens up a whole rats nest of design decisions and compromises that CLTV doesn't. Yet CLTV itself is a big step forward, it's been implemented on Viacoin for the past few months with no issues found, and has an extremely simple and easy to audit implementation. I think I'm going to argue we implement it as-is in a soft-fork. Pieter Wuille's been working on a new way to handle soft-fork upgrades in the block nVersion field, so this would be a good opportunity to add something simple and well tested, and also make sure the new nVersion soft-fork mechanism works. Equally, doing both at the same time ensures we don't burn yet another version bit. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote:
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).
Wait, wait, this can be made reorg-safe and more backards compatible.
The new validation rule at the tx validation level (currently in
main::CheckInputs()) would be
for (unsigned int i = 0; i tx.vin.size(); i++) {
// ...
if (tx.vin.nHeight + 100 tx.nLockTime)
return state.Invalid(false, REJECT_INVALID,
bad-txns-vin-height-reorg-unsafe);
if (coins-nHeight tx.vin.nHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-vin-height-false);
// ...
}
Existing transactions that have used the deprecated CTxIn::nSequence
for something else will be fine if they've used low nSequences.
The only concern would be breaking some colored coins kernels, but
there's many others implemented that don't rely on CTxIn::nSequence.
Transactions that want to use OP_MATURITY just have to set the
corresponding CTxIn::nHeight and CTransaction::nLockTime properly.
This way op_maturity wouldn't require anything from the utxo and the
final interface could be:
int bitcoinconsensus_verify_script(const unsigned char* scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char* txTo,
unsigned int txToLen,
unsigned int nIn, unsigned int nHeight,
unsigned int flags,
secp256k1_context_t* ctx,
bitcoinconsensus_error* err);
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd p...@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
015e09479548c5b63b99a62d31b019e6479f195bf0cbd935
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Mon, Mar 16, 2015 at 10:22:13PM +, 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. 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
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
I'm in favor of relative CHECKLOCKTIMEVERIFY, but I don't have a very specific reason. I just have a vague worry that there can be race conditions in which a txn with an absolute CHECKLOCKTIMEVERIFY goes into the blockchain later than one of its signers expected that it would, and therefore there is a surprisingly short delay between that transaction going into the blockchain and becoming spendable. This worry of mine is assuaged by using relative CHECKLOCKTIMEVERIFY instead. Regards, Zooko -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
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. 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. 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). Thoughts? Matt On 10/01/14 13:08, Peter Todd wrote: I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at: https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki The reference implementation, including a full-set of unittests for the opcode semantics can be found at: https://github.com/petertodd/bitcoin/compare/checklocktimeverify pre BIP: Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd p...@petertodd.org Status: Draft Type: Standards Track Created: 2014-10-01 /pre ==Abstract== This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future. ==Summary== CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it compares the top item on the stack to the nLockTime field of the transaction containing the scriptSig. If that top stack item is greater than the transation nLockTime the script fails immediately, otherwise script evaluation continues as though a NOP was executed. The nLockTime field in a transaction prevents the transaction from being mined until either a certain block height, or block time, has been reached. By comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we indirectly verify that the desired block height or block time has been reached; until that block height or block time has been reached the transaction output remains unspendable. ==Motivation== The nLockTime field in transactions makes it possible to prove that a transaction output can be spent in the future: a valid signature for a transaction with the desired nLockTime can be constructed, proving that it is possible to spend the output with that signature when the nLockTime is reached. An example where this technique is used is in micro-payment channels, where the nLockTime field proves that should the receiver vanish the sender is guaranteed to get all their escrowed funds back when the nLockTime is reached. However the nLockTime field is insufficient if you wish to prove that transaction output ''can-not'' be spent until some time in the future, as there is no way to prove that the secret keys corresponding to the pubkeys controling the funds have not been used to create a valid signature. ===Escrow=== If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting hit by a bus they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party. With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force. However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of the form: IF now + 3 months CHECKLOCKTIMEVERIFY DROP Lenny's pubkey CHECKSIGVERIFY
