Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Tue, May 5, 2015 at 10:38 PM, Tier Nolan wrote:
> 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.
Yes, sorry, I changed it just before sending from "what needs to be
satisfied for the validation error to trigger" to "what needs to be
satisfied for the tx to be valid".
You're right.
> 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");
Yes, this would be the simplest solution. Another option would be to
have a new tx version in which IsFinal(CTransaction) doesn't check the
inputs sequences to be 0x for the tx to be final.
> Is the intention to let the script check the sequence number?
>
> OP_RELATIVELOCKTIMEVERIFY
>
> would check if is less than or equal to the sequence number.
Yes.
> It does make sequence mean something completely different from before.
> Invalidating previously valid transactions has the potential to reduce
> confidence in the currency.
Well, the semantics of nSequence don't really change completely. In
fact, one could argue that this put it closer to its original
semantics.
But in any case, yes, already signed transaction should remain valid.
No transaction would become invalid, just non-final.
As soon as the height of its inputs plus their respective nSquences
get higher than current height they will become final again.
I cannot think of any use case where a tx becomes invalid forever.
Also, probably most people have usedrelatively low values for
nSequence given the original semantics, just like the relative lock
nSquence will likely be used as well.
> 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
To be clear, this proposal is supposed to replace RCLTV, so there
would still be 2 options. But please let's imagine we have infinite
opcodes in this thread and let the "should we design an uglier
scripting langues to save opcodes?" question in the other one.
> 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");
This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
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
[email protected]
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?
OP_RELATIVELOCKTIMEVERIFY
would check if 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 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Well, apparently the timestamp can be make compatible with Mark's
nSequence-based RCLTV by adding an additional check at the block level
but I was only explaining the concept using heights (which is the most
interesting part IMO).
I'm also not sure I understood the details and I don't want to confuse
people again, so I'll wait for someone else to explain that part.
ACLTV can work with timestamps too unless I'm missing something. It's
just more complexity and I was never convinced that there's enough use
cases relying on timestamps to justify them. But the timestamp
discussion is quite orthogonal to the nSequence-based RCLTV proposal
itself.
On Tue, May 5, 2015 at 2:41 AM, Btc Drak wrote:
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
>>
>> 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.
>
>
> Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For
> absolute CLTV I think it's important to have timestamps so that trust fund
> use cases are practical (e.g. spendable on 18th birthday), because the exact
> date a future block will be mined on is unpredictable if it's far enough in
> the future (out by days or even weeks).
>
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
> 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.
Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For
absolute CLTV I think it's important to have timestamps so that trust fund
use cases are practical (e.g. spendable on 18th birthday), because the
exact date a future block will be mined on is unpredictable if it's far
enough in the future (out by days or even weeks).
--
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
[email protected]
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
[email protected]
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 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 re
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" 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 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 > > > > 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 [email protected] 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 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 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 [email protected] 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 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
[email protected]
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 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 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/1P
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 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 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 goi
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 [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
