CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
46 messages, 1 Oct 2014 to 6 May 2015. Started by Peter Todd.
Peter Todd (10), Jorge Timón (6), Gavin Andresen (4), Mike Hearn (4), Luke Dashjr (3), Greg Maxwell (3), Alan Reiner (2), Matt Whitlock (2), +10 more
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 <pete@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
1
ELSE
2
ENDIF
<Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
At any time the funds can be spent with the following scriptSig:
<Alice's signature> <Bob's signature> 0
After 3 months have passed Lenny and one of either Alice or Bob can spend the funds with the following scriptSig:
<Alice/Bob's signature> <Lenny's signature> 1
===Non-interactive time-locked refunds===
There exist a number of protocols where a transaction output is created that the co-operation of both parties to spend the output. To ensure the failure of one party does not result in the funds becoming lost refund transactions are setup in advance using nLockTime. These refund transactions need to be created interactively, and additionaly, are currently vulnerable to transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the interactive setup with a non-interactive setup, and additionally, making transaction mutability a non-issue.
====Two-factor wallets====
Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's such that one keypair is controlled by the user, and the other keypair is controlled by the service. To spend funds the user uses locally installed wallet software that generates one of the required signatures, and then uses a 2nd-factor authentication method to authorize the service to create the second SIGHASH_NONE signature that is locked until some time in the future and sends the user that signature for storage. If the user needs to spend their funds and the service is not available, they wait until the nLockTime expires.
The problem is there exist numerous occasions the user will not have a valid signature for some or all of their transaction outputs. With CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand scriptPubKeys of the following form are used instead:
IF
<service pubkey> CHECKSIGVERIFY
ELSE
<expiry time> CHECKLOCKTIMEVERIFY DROP
ENDIF
<user pubkey> CHECKSIG
Now the user is always able to spend their funds without the co-operation of the service by waiting for the expiry time to be reached.
====Micropayment Channels====
Jeremy Spilman style micropayment channels first setup a deposit controlled by 2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends the output of tx1 to payor and payee. Prior to publishing tx1 a refund transaction is created, tx3, to ensure that should the payee vanish the payor can get their deposit back. The process by which the refund transaction is created is currently vulnerable to transaction mutability attacks, and additionally, requires the payor to store the refund. Using the same scriptPubKey from as in the Two-factor wallets example solves both these issues.
===Trustless Payments for Publishing Data===
The PayPub protocol makes it possible to pay for information in a trustless way by first proving that an encrypted file contains the desired data, and secondly crafting scriptPubKeys used for payment such that spending them reveals the encryption keys to the data. However the existing implementation has a significant flaw: the publisher can delay the release of the keys indefinitely.
This problem can be solved interactively with the refund transaction technique; with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using scriptPubKeys of the following form:
IF
HASH160 <Hash160(encryption key)> EQUALVERIFY
<publisher pubkey> CHECKSIG
ELSE
<expiry time> CHECKLOCKTIMEVERIFY DROP
<buyer pubkey> CHECKSIG
ENDIF
The buyer of the data is now making a secure offer with an expiry time. If the publisher fails to accept the offer before the expiry time is reached the buyer can cancel the offer by spending the output.
===Proving sacrifice to miners' fees===
Proving the sacrifice of some limited resource is a common technique in a variety of cryptographic protocols. Proving sacrifices of coins to mining fees has been proposed as a ''universal public good'' to which the sacrifice could be directed, rather than simply destroying the coins. However doing so is non-trivial, and even the best existing technqiue - announce-commit sacrifices - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone (thus to mining fees assuming miners behave optimally and rationally) but only at a time sufficiently far into the future that large miners profitably can't sell the sacrifices at a discount.
===Replacing the nLockTime field entirely===
As an aside, note how if the SignatureHash() algorithm could optionally cover part of the scriptSig the signature could require that the scriptSig contain CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. (the CODESEPARATOR opcode came very close to making this possible in v0.1 of Bitcoin) This per-signature capability could replace the per-transaction nLockTime field entirely as a valid signature would now be the proof that a transaction output ''can'' be spent.
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise semantics and detailed rationale for those semantics.
case OP_NOP2:
{
// CHECKLOCKTIMEVERIFY
//
// (nLockTime -- nLockTime )
if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY))
break; // not enabled; treat as a NOP
if (stack.size() < 1)
return false;
// Note that elsewhere numeric opcodes are limited to
// operands in the range -2**31+1 to 2**31-1, however it is
// legal for opcodes to produce results exceeding that
// range. This limitation is implemented by CScriptNum's
// default 4-byte limit.
//
// If we kept to that limit we'd have a year 2038 problem,
// even though the nLockTime field in transactions
// themselves is uint32 which only becomes meaningless
// after the year 2106.
//
// Thus as a special case we tell CScriptNum to accept up
// to 5-byte bignums, which are good until 2**32-1, the
// same limit as the nLockTime field itself.
const CScriptNum nLockTime(stacktop(-1), 5);
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKLOCKTIMEVERIFY.
if (nLockTime < 0)
return false;
// There are two times of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of nLockTime being tested is the same as
// the nLockTime in the transaction.
if (!(
(txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) ||
(txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
))
return false;
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nLockTime > (int64_t)txTo.nLockTime)
return false;
// Finally the nLockTime feature can be disabled and thus
// CHECKLOCKTIMEVERIFY bypassed if every txin has been
// finalized by setting nSequence to maxint. The
// transaction would be allowed into the blockchain, making
// the opcode ineffective.
//
// Testing if this vin is not final is sufficient to
// prevent this condition. Alternatively we could test all
// inputs, but testing just this input minimizes the data
// required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo.vin[nIn].IsFinal())
return false;
break;
}
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
==Upgrade and Testing Plan==
TBD
==Credits==
Thanks goes to Gregory Maxwell for suggesting that the argument be compared against the per-transaction nLockTime, rather than the current block height and time.
==References==
PayPub - https://github.com/unsystem/paypub
Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
==Copyright==
This document is placed in the public domain.
Very nice, semantics are clear and use cases are compelling.
Can we defer discussion of how to roll this out for a little bit, and see if there is consensus that:
a) benefits of having this outweigh risks b) we're all happy with exact semantics
Then we can have a knock-down drag-out argument about whether it should roll out as a soft fork, wait for a hard fork, be combined with some other things that it would be nice to add or change, etc.....
I like the proposal.
I suggest that applications and nodes should only broadcast transactions having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value. If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is equal to the current height and equal to the timeout value, but that peer is one block behind in the blockchain, the transaction will be rejected by the peer and the source will be banned.
Another option will be not to ban peers sending transactions failing to verify OP_CHECKLOCKTIMEVERIFY , but I don't like this.
Still another option would be that the sender checks periodically the height of it's peers (using the version command) in order to be sure to send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers that are up to date with the blockchain.
Regards, Sergio.
Yeah, there are lots of "upper-level" details to consider; I'm not going to pretend that BIP is complete yet. My thinking is that the first release should include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that blacklist for another minor release or two.
On 1 October 2014 11:29:48 GMT-04:00, Sergio Lerner <sergiolerner@certimix•com> wrote:
Quoted text (36 lines)
>I like the proposal. > >I suggest that applications and nodes should only broadcast >transactions >having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value. >If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime >is >equal to the current height and equal to the timeout value, but that >peer is one block behind in the blockchain, the transaction will be >rejected by the peer and the source will be banned. > >Another option will be not to ban peers sending transactions failing to >verify OP_CHECKLOCKTIMEVERIFY , but I don't like this. > >Still another option would be that the sender checks periodically the >height of it's peers (using the version command) in order to be sure to >send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers >that are up to date with the blockchain. > >Regards, > Sergio. > > > > >------------------------------------------------------------------------------ >Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS >Reports >Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge•net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
Quoted text (2 lines)
> I've written a reference implementation and BIP draft for a new opcode, > CHECKLOCKTIMEVERIFY.
Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? A limitation of encoding the target height/time directly, is that miners may choose not to mine the first transaction until they can also take the "burn to fee". So, one may prefer to say "cannot be spent until 100 blocks after the first transaction is mined", in effect reproducing the generation maturity rule.
I propose any stack item under 0x40000 be incremented by the height at which the scriptPubKey was mined for comparison. Maybe there is a use case for doing something similar for time too?
Luke
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (5 lines)
> houghts on some way to have the stack item be incremented by the height at > which the scriptPubKey was in a block? A limitation of encoding the target > height/time directly, is that miners may choose not to mine the first > transaction until they can also take the "burn to fee". >
If the first transaction is P2SH, then the miner won't know there is an advantage to holding it until it is too late (the scriptPubKey is an opaque hash until the second transaction is final and relayed/broadcast).
On 10/01/2014 04:58 PM, Gavin Andresen wrote:
Quoted text (4 lines)
> If the first transaction is P2SH, then the miner won't know there is > an advantage to holding it until it is too late (the scriptPubKey is > an opaque hash until the second transaction is final and > relayed/broadcast).
If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH defeat the purpose of it?
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner <etotheipi@gmail•com> wrote:
Quoted text (9 lines)
> On 10/01/2014 04:58 PM, Gavin Andresen wrote: > > If the first transaction is P2SH, then the miner won't know there is > > an advantage to holding it until it is too late (the scriptPubKey is > > an opaque hash until the second transaction is final and > > relayed/broadcast). > > If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH > defeat the purpose of it? >
No, the burner would supply the funding transaction plus the redeeming script as the proof-of-burn to whoever needed the proof.
Only after at least one confirmation, if there was some risk that revealing the redeeming script would make miners refuse to mine that first transaction because they want to get it plus the CHECKTIMELOCKVERIFY "burn" transaction.
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (3 lines)
>Thoughts on some way to have the stack item be incremented by the >height at >which the scriptPubKey was in a block?
Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. scriptPubKey would be:
GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
(fails unless top stack item is equal to the txin block height)
<delta height> ADD
(top stack item is now txin height + delta height)
CHECKLOCKTIMEVERIFY
Quoted text (8 lines)
> A limitation of encoding the >target >height/time directly, is that miners may choose not to mine the first >transaction until they can also take the "burn to fee". So, one may >prefer to >say "cannot be spent until 100 blocks after the first transaction is >mined", >in effect reproducing the generation maturity rule.
You'd want these sacrifices to unlock years into the future to thoroughly exceed any reasonable business cycle; that's so far into the future that miners are almost certain to just mine them and collect the fees.
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (4 lines)
>On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner <etotheipi@gmail•com> >wrote: >No, the burner would supply the funding transaction plus the redeeming >script as the proof-of-burn to whoever needed the proof.
No, the redeemScript has to be provably published to miners for the sacrifice to be valid; if not you can exploit the scheme by hiding the redeemScript and having a big miner mine it at lower-than-face-value cost when it unlocks.
Quoted text (6 lines)
>Only after at least one confirmation, if there was some risk that >revealing >the redeeming script would make miners refuse to mine that first >transaction because they want to get it plus the CHECK TIME BLOCK VERIFY >"burn" >transaction.
Yes, you could do that in a followup tx containing the redeemScript in an OP_RETURN output to prove publication. That said as I said to Luke-Jr, the sacrifices need to unlock pretty far into the future, so I don't see miners bothering to do this.
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
Quoted text (12 lines)
> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote: > >Thoughts on some way to have the stack item be incremented by the > >height at > >which the scriptPubKey was in a block? > > Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. > scriptPubKey would be: > GET-TXIN-BLOCKHEIGHT-EQUALVERIFY > (fails unless top stack item is equal to the txin block height) > <delta height> ADD > (top stack item is now txin height + delta height) > CHECKLOCKTIMEVERIFY
This sounds do-able, although it doesn't address using timestamps.
Quoted text (11 lines)
> > A limitation of encoding the target > >height/time directly, is that miners may choose not to mine the first > >transaction until they can also take the "burn to fee". So, one may > >prefer to > >say "cannot be spent until 100 blocks after the first transaction is > >mined", > >in effect reproducing the generation maturity rule. > > You'd want these sacrifices to unlock years into the future to thoroughly > exceed any reasonable business cycle; that's so far into the future that > miners are almost certain to just mine them and collect the fees.
For many use cases, short maturity periods are just as appropriate IMO.
Luke
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen <gavinandresen@gmail•com> wrote:
Quoted text (1 line)
>Very nice, semantics are clear and use cases are compelling.
Thanks!
Quoted text (11 lines)
>Can we defer discussion of how to roll this out for a little bit, and >see >if there is consensus that: > >a) benefits of having this outweigh risks >b) we're all happy with exact semantics > >Then we can have a knock-down drag-out argument about whether it should >roll out as a soft fork, wait for a hard fork, be combined with some >other >things that it would be nice to add or change, etc.....
Agreed. People should keep in mind that leaving the deployment details as "TBD" was quite deliberate. There is some code in the repo to implement a softfork, but it's only meant to be illustrative.
On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (16 lines)
>On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> >wrote: >> >Thoughts on some way to have the stack item be incremented by the >> >height at >> >which the scriptPubKey was in a block? >> >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. >> scriptPubKey would be: >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY >> (fails unless top stack item is equal to the txin block height) >> <delta height> ADD >> (top stack item is now txin height + delta height) >> CHECKLOCKTIMEVERIFY > >This sounds do-able, although it doesn't address using timestamps.
For timestamps replace "height" with "time" in the above example; the minimum block time rule will prevent gaming it.
Quoted text (7 lines)
>> You'd want these sacrifices to unlock years into the future to >thoroughly >> exceed any reasonable business cycle; that's so far into the future >that >> miners are almost certain to just mine them and collect the fees. > >For many use cases, short maturity periods are just as appropriate IMO.
Very easy to incentivise mining centralisation with short maturities. I personally think just destroying coins is better, but it doesn't sit well with people so this is the next best thing.
Very good, I like the proposal.
A question I have: can it be used to do the opposite, i.e. build a script that can only be spent up until block X?
On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (66 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote: > >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: > >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> > >wrote: > >> >Thoughts on some way to have the stack item be incremented by the > >> >height at > >> >which the scriptPubKey was in a block? > >> > >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. > >> scriptPubKey would be: > >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY > >> (fails unless top stack item is equal to the txin block height) > >> <delta height> ADD > >> (top stack item is now txin height + delta height) > >> CHECKLOCKTIMEVERIFY > > > >This sounds do-able, although it doesn't address using timestamps. > > For timestamps replace "height" with "time" in the above example; the > minimum block time rule will prevent gaming it. > > > >> You'd want these sacrifices to unlock years into the future to > >thoroughly > >> exceed any reasonable business cycle; that's so far into the future > >that > >> miners are almost certain to just mine them and collect the fees. > > > >For many use cases, short maturity periods are just as appropriate IMO. > > Very easy to incentivise mining centralisation with short maturities. I > personally think just destroying coins is better, but it doesn't sit well > with people so this is the next best thing. > -----BEGIN PGP SIGNATURE----- > Version: APG v1.1.1 > > iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o > JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV > f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb > 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr > 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm > vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq > SOgO > =WybM > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including "output cannot be spent until a certain time" and also "output can ONLY be spent until a certain time," as well as complex logic with alternative key groups with differing time constraints.
OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.
On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote:
Quoted text (73 lines)
> Very good, I like the proposal. > > A question I have: can it be used to do the opposite, i.e. build a script > that can only be spent up until block X? > > On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete@petertodd•org> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote: > > >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: > > >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> > > >wrote: > > >> >Thoughts on some way to have the stack item be incremented by the > > >> >height at > > >> >which the scriptPubKey was in a block? > > >> > > >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. > > >> scriptPubKey would be: > > >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY > > >> (fails unless top stack item is equal to the txin block height) > > >> <delta height> ADD > > >> (top stack item is now txin height + delta height) > > >> CHECKLOCKTIMEVERIFY > > > > > >This sounds do-able, although it doesn't address using timestamps. > > > > For timestamps replace "height" with "time" in the above example; the > > minimum block time rule will prevent gaming it. > > > > > > >> You'd want these sacrifices to unlock years into the future to > > >thoroughly > > >> exceed any reasonable business cycle; that's so far into the future > > >that > > >> miners are almost certain to just mine them and collect the fees. > > > > > >For many use cases, short maturity periods are just as appropriate IMO. > > > > Very easy to incentivise mining centralisation with short maturities. I > > personally think just destroying coins is better, but it doesn't sit well > > with people so this is the next best thing. > > -----BEGIN PGP SIGNATURE----- > > Version: APG v1.1.1 > > > > iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 > > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o > > JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV > > f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb > > 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr > > 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm > > vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq > > SOgO > > =WybM > > -----END PGP SIGNATURE----- > > > > > > > > ------------------------------------------------------------------------------ > > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge•net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
Oops, sorry. I meant: replace the top stack item with the block height of the txin doing the redeeming. (So the script can calculate the "current time" to some reference time embedded in the script.)
On Friday, 3 October 2014, at 10:28 am, Matt Whitlock wrote:
Quoted text (79 lines)
> Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including "output cannot be spent until a certain time" and also "output can ONLY be spent until a certain time," as well as complex logic with alternative key groups with differing time constraints. > > OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO. > > > On Thursday, 2 October 2014, at 4:05 pm, Flavien Charlon wrote: > > Very good, I like the proposal. > > > > A question I have: can it be used to do the opposite, i.e. build a script > > that can only be spent up until block X? > > > > On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete@petertodd•org> wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA256 > > > > > > > > > > > > On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke@dashjr•org> wrote: > > > >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: > > > >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke@dashjr•org> > > > >wrote: > > > >> >Thoughts on some way to have the stack item be incremented by the > > > >> >height at > > > >> >which the scriptPubKey was in a block? > > > >> > > > >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator. > > > >> scriptPubKey would be: > > > >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY > > > >> (fails unless top stack item is equal to the txin block height) > > > >> <delta height> ADD > > > >> (top stack item is now txin height + delta height) > > > >> CHECKLOCKTIMEVERIFY > > > > > > > >This sounds do-able, although it doesn't address using timestamps. > > > > > > For timestamps replace "height" with "time" in the above example; the > > > minimum block time rule will prevent gaming it. > > > > > > > > > >> You'd want these sacrifices to unlock years into the future to > > > >thoroughly > > > >> exceed any reasonable business cycle; that's so far into the future > > > >that > > > >> miners are almost certain to just mine them and collect the fees. > > > > > > > >For many use cases, short maturity periods are just as appropriate IMO. > > > > > > Very easy to incentivise mining centralisation with short maturities. I > > > personally think just destroying coins is better, but it doesn't sit well > > > with people so this is the next best thing. > > > -----BEGIN PGP SIGNATURE----- > > > Version: APG v1.1.1 > > > > > > iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 > > > cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o > > > JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV > > > f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb > > > 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr > > > 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm > > > vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq > > > SOgO > > > =WybM > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > > > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > > > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > > > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge•net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:
Quoted text (1 line)
> Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed?
This would not be soft-forking compatible.
It also would be unsafe in that it would result in transactions which once mined could not be restored in a reorg through no fault of the participants, which makes the coins less fungible and differently safe to accept. It risks creating weird pressures around immediate block admission since a one additional block delay could forever censor such a transaction (E.g. increases the power of single miners to censor or steal). Avoiding this is a conscious decision in Bitcoin and also part of the justification for the 100 block maturity of newly generated coins.
It also would require violating the script/transaction/block layering more substantially, complicating implementations, and making the validity of a script no longer a deterministic pure function of the transaction.
Avoiding these issues is a conscious design in OP_CHECKLOCKTIMEVERIFY. I would strenuously oppose a proposal which failed in any of these respects.
Quoted text (1 line)
> Then arbitrary logic could be implemented, including "output cannot be spent until a certain time" and also "output can ONLY be spent until a certain time," as well as complex logic with alternative key groups with differing time constraints.
You can already achieve the not spendable after logic with a cancellation spend that moves the coin in the usual way. (Which doesn't even require the participant be online, with the help of some network service to queue unlocked transactions).
Quoted text (1 line)
> OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.
It is intentionally so, and yet it covers the intended use cases; including ones with alternative key groups, they are just not exclusive.
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
Quoted text (6 lines)
> Is there a reason why we can't have the new opcode simply replace the top > stack item with the block height of the txout being redeemed? Then > arbitrary logic could be implemented, including "output cannot be spent > until a certain time" and also "output can ONLY be spent until a certain > time," as well as complex logic with alternative key groups with differing > time constraints.
This cannot be done in a softfork.
Furthermore, "output can ONLY be spent until a certain time" contradict's Bitcoin's present security assumptions: that assuming a honest sender, the transaction will remain valid and simply re-confirm if a reorg kicks it out.
Luke
Alright. It seems there's no real disagreement about how the opcode behaves. Perhaps a time limit would be appropriate to stop people creating outputs locked for 100 years .... is bitcoin even likely to exist in 100 years? The entire history of computing is not even that old, seems hard to imagine that it'd be good for anything beyond wasting space in the database. But this is a minor point.
So I guess it's time to start the deployment discussion.
Bitcoin is a consensus system. It works best when everyone is following exactly the same rules at the same time. A soft fork works against this principle by allowing nodes to think they're following the majority ruleset, even if they aren't, effectively downgrading them to something a bit like SPV security without them realising.
A hard fork has multiple desirable properties. Most importantly, it means a node can detect it's no longer in the consensus because it'll find its own chain height has diverged significantly from its peers. Core already has code that knows how to detect this condition and log errors about it as well as running the alertnotify script i.e. emailing the admin. Ideally it would also stop serving work so miners shut down or fail over, but this is easily added to the CheckForkWarningConditions() function.
In other words, this gives the cleanest failure we can give, such that any procedures a node operator has put in place to alert them of divergence will be triggered. Any code which is waiting for confirmations will wait forever at this point, thus minimising the risk of loss.
Additionally, forcing old peers to fall behind means SPV clients will pick the right chain, and not end up downloading transactions or blocks that are about to be doomed at the next re-org. They can easily choose to ignore transactions relayed by peers that are too far behind and thus not end up accepting transactions that are no longer valid according to the majority (a scenario which can cause monetary loss).
I don't think hard forks should be scary. Mechanisms are in place to warn people and they can be scheduled with plenty of time in advance. The main stated justification for a soft fork is backwards compatibility, but in a system like Bitcoin you really don't want to be running behind the consensus and it's hard to imagine any node operator deliberately choosing to stay on the wrong side of the fork. It's not like other software where people can choose to skip an upgrade and things still work just like before.
RE " It's not like other software where people can choose to skip an upgrade and things still work just like before."
If you're a minority, sure you can. Still a few nutters out there on a 0.3.x codebase, including one or two inattentive, now-inconsequential miners.
There is some headroom built in for just that... less disruptive upgrades that don't require 100%.
On Fri, Oct 3, 2014 at 4:58 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (54 lines)
> Alright. It seems there's no real disagreement about how the opcode behaves. > Perhaps a time limit would be appropriate to stop people creating outputs > locked for 100 years .... is bitcoin even likely to exist in 100 years? The > entire history of computing is not even that old, seems hard to imagine that > it'd be good for anything beyond wasting space in the database. But this is > a minor point. > > So I guess it's time to start the deployment discussion. > > Bitcoin is a consensus system. It works best when everyone is following > exactly the same rules at the same time. A soft fork works against this > principle by allowing nodes to think they're following the majority ruleset, > even if they aren't, effectively downgrading them to something a bit like > SPV security without them realising. > > A hard fork has multiple desirable properties. Most importantly, it means a > node can detect it's no longer in the consensus because it'll find its own > chain height has diverged significantly from its peers. Core already has > code that knows how to detect this condition and log errors about it as well > as running the alertnotify script i.e. emailing the admin. Ideally it would > also stop serving work so miners shut down or fail over, but this is easily > added to the CheckForkWarningConditions() function. > > In other words, this gives the cleanest failure we can give, such that any > procedures a node operator has put in place to alert them of divergence will > be triggered. Any code which is waiting for confirmations will wait forever > at this point, thus minimising the risk of loss. > > Additionally, forcing old peers to fall behind means SPV clients will pick > the right chain, and not end up downloading transactions or blocks that are > about to be doomed at the next re-org. They can easily choose to ignore > transactions relayed by peers that are too far behind and thus not end up > accepting transactions that are no longer valid according to the majority (a > scenario which can cause monetary loss). > > I don't think hard forks should be scary. Mechanisms are in place to warn > people and they can be scheduled with plenty of time in advance. The main > stated justification for a soft fork is backwards compatibility, but in a > system like Bitcoin you really don't want to be running behind the consensus > and it's hard to imagine any node operator deliberately choosing to stay on > the wrong side of the fork. It's not like other software where people can > choose to skip an upgrade and things still work just like before. > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote:
Quoted text (9 lines)
> RE " It's not like other software where people can choose to skip an > upgrade and things still work just like before." > > If you're a minority, sure you can. Still a few nutters out there on > a 0.3.x codebase, including one or two inattentive, > now-inconsequential miners. > > There is some headroom built in for just that... less disruptive > upgrades that don't require 100%.
Anyway the stuff Mike is saying about being able to detect upgrades is incorrect - detecting an upgrade is *easier* with a soft-fork, just look at the block header nVersion numbers and warn the user if they increase beyond what you know is valid. Bitcoin Core implements this IIRC, and bitcoinj should.
Someone with more time should write all this up for the bitcoin.org developer docs BTW... There's extensive discussions on #bitcoin-dev and others about all of this.
Quoted text (7 lines)
> > Anyway the stuff Mike is saying about being able to detect upgrades is > incorrect - detecting an upgrade is *easier* with a soft-fork, just look > at the block header nVersion numbers and warn the user if they increase > beyond what you know is valid. Bitcoin Core implements this IIRC, and > bitcoinj should. >
Nobody said hard forks shouldn't have an associated block version number increase - that's a straw man. They should! The difference is only whether older clients are presented with data they would refuse to accept thus ensuring they don't accept the new version blocks.
Meanwhile, what I said *is* correct. New version numbers result in only a log print. Being hard forked off results in both log prints *and* the -alertnotify being run: it's noisier, and if the user followed the instructions printed to the console when there is no config file present, he/she should also get an email or some other kind of more meaningful alert.
Finally, please stop trying to imply that all this is settled and I'm somehow an idiot for bringing it up. You've done that on the pull request and now here, it gives me a headache. Instead of making hand-waving references to "stuff on IRC ages ago", explain why it's better to keep these nodes in some fantasy world where they think they're fully validating but are actually not.
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (5 lines)
> >> Meanwhile, what I said *is* correct. New version numbers result in only > a log print. Being hard forked off results in both log prints *and* the > -alertnotify being run: >
That is easy to change; I'll submit a pull request. It is a good idea to get an -alertnotify sooner rather than later for EITHER a hard fork or a soft-fork. Better to be told you have to upgrade while the block.version is on its way to being a super-majority than after you are either hard-forked off the main chain (or soft-forked).
I don't have any opinion on the hard- versus soft- fork debate. I think either can work.
Quoted text (3 lines)
> > That is easy to change; I'll submit a pull request. >
That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. If there's going to be an intermediate release (6 months?) which lays the groundwork for future rule changes, it helps more.
It would be good if getblocktemplate was updated at the same time to serve errors if the fork warning is active. I'd hope miners have some way to automatically handle IBD/getting forked off the chain, but I guess some (newer) pools might not, and refusing to serve work should be the safest option that shuts them down.
I don't have any opinion on the hard- versus soft- fork debate. I think
Quoted text (2 lines)
> either can work. >
P2SH was a soft fork and the sky did not fall, but miners did lose money and waste electricity mining blocks on the wrong side of the chain:
https://bitcointalk.org/index.php?topic=75294.0
Presumably they didn't notice for longer because it looked like a run of unusually bad orphaning luck. It seems safer to have a clean fork, with alerts telling people during the lockin period before new rule enforcement starts (and possibly automated termination if there's no upgrade by the flag day?). Miners who ignore it would still risk losing money, but merchants who wait for a block at least would not be at risk.
One open question is how can you actually trigger a hard fork? Coinbase scriptSigs are not executed, so putting some ignored but failing opcode sequence there wouldn't work. One possibility would be to have a special invalid tx in the block that marks the start of new rule enforcement. New nodes would know to ignore it. But this risks corrupting block explorers. Alternatively the coinbase outpoint structure could have its hash set to 1 instead of 0.
On 10/7/2014 8:50 AM, Gavin Andresen wrote:
Quoted text (4 lines)
> > I don't have any opinion on the hard- versus soft- fork debate. I > think either can work. >
Opinion: if a soft work works, it should be preferred, if for no other reason than once a hard-fork is planned, the discussion begins about what else to throw in. To minimize the frequency of hard-forks, the time for that is when the change being considered actually requires one.
Quoted text (5 lines)
> > Opinion: if a soft work works, it should be preferred, if for no other > reason than once a hard-fork is planned, the discussion begins about > what else to throw in. To minimize the frequency of hard-forks, the > time for that is when the change being considered actually requires one.
I'm not sure why it'd be any different. Soft forks are just as disruptive - everyone who needs a correct node has to upgrade on time. Given that, I guess there will be a desire to roll out several changes at once too, regardless of what happens to older nodes.
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn <mike@plan99•net> wrote:
Quoted text (5 lines)
>> That is easy to change; I'll submit a pull request. > > > That's certainly a useful improvement. It won't help the existing userbase > though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
The next minor release (0.9.4) could have Gavin's change already.
I don't think CHECKLOCKTIMEVERIFY will make it into the next major release though. Once headers-first and pruning is merged (which is expected to be a matter of weeks). I'd like to split off the 0.10 branch and give it some time to stabilize with a feature freeze, then do a release before the end of the year.
So 0.11, in say 6 months, would be soonest.
Wladimir
By the way, I really like this proposal. I haven't spent much time thinking about the deeper subtleties and risks associated with it, but I see a lot of opportunities. One just came to mind that I didn't see mentioned in his original proposal:
_Non-Interactive Recurring payments__with ID-association_: You want to make N recurring payments of 1 BTC each month to a service. Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number approximately X months in the future (one for each month). The script allows the customer to move the coins at any time, but after the locktime the merchant/service has signing access. The merchant software will continually watch for and sweep all coins that become available via this mechanism and credit the appropriate customer account. The customer maintains control of the funds until payment time, the merchant can automatically collect it each month without requiring user interaction, and the customer can cancel it just by spending it elsewhere before the locktime.
This scheme has an added benefit: both the merchant's address and the user's address is in the script. Given an appropriate scheme for linking addresses to accounts (perhaps sending the service a watch-only BIP32 branch), the service can use the other address in the script to recognize and link that payment to the user's account. This allows you to continue paying and extending your subscription without having to explicitly link each payment to the account. The wallet will simply make sure to use a return address that is in a BIP32 branch that was provided to the service during signup, and the service will automatically extend your subscription every month based on that info when it sweeps payments.
Along with everything else that was mentioned by Peter in his original proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a simple improvement.
-Alan
On 10/08/2014 06:26 AM, Wladimir wrote:
Quoted text (27 lines)
> On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn <mike@plan99•net> wrote: >>> That is easy to change; I'll submit a pull request. >> >> That's certainly a useful improvement. It won't help the existing userbase >> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. > The next minor release (0.9.4) could have Gavin's change already. > > I don't think CHECKLOCKTIMEVERIFY will make it into the next major > release though. Once headers-first and pruning is merged (which is > expected to be a matter of weeks). I'd like to split off the 0.10 > branch and give it some time to stabilize with a feature freeze, then > do a release before the end of the year. > > So 0.11, in say 6 months, would be soonest. > > Wladimir > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and work-around malleability until that is fully fixed) just to get the effect.
When I tried building things that need nlocktime I found it quite inconvenient that it was wasnt a function rather than a script property, so I like this proposal.
Adam
On 9 October 2014 04:13, Alan Reiner <etotheipi@gmail•com> wrote:
Quoted text (82 lines)
> By the way, I really like this proposal. I haven't spent much time thinking > about the deeper subtleties and risks associated with it, but I see a lot of > opportunities. One just came to mind that I didn't see mentioned in his > original proposal: > > Non-Interactive Recurring payments with ID-association: > You want to make N recurring payments of 1 BTC each month to a service. > Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number > approximately X months in the future (one for each month). The script > allows the customer to move the coins at any time, but after the locktime > the merchant/service has signing access. The merchant software will > continually watch for and sweep all coins that become available via this > mechanism and credit the appropriate customer account. The customer > maintains control of the funds until payment time, the merchant can > automatically collect it each month without requiring user interaction, and > the customer can cancel it just by spending it elsewhere before the > locktime. > > This scheme has an added benefit: both the merchant's address and the > user's address is in the script. Given an appropriate scheme for linking > addresses to accounts (perhaps sending the service a watch-only BIP32 > branch), the service can use the other address in the script to recognize > and link that payment to the user's account. This allows you to continue > paying and extending your subscription without having to explicitly link > each payment to the account. The wallet will simply make sure to use a > return address that is in a BIP32 branch that was provided to the service > during signup, and the service will automatically extend your subscription > every month based on that info when it sweeps payments. > > Along with everything else that was mentioned by Peter in his original > proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a > simple improvement. > > -Alan > > > > On 10/08/2014 06:26 AM, Wladimir wrote: > > On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn <mike@plan99•net> wrote: > > That is easy to change; I'll submit a pull request. > > That's certainly a useful improvement. It won't help the existing userbase > though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. > > The next minor release (0.9.4) could have Gavin's change already. > > I don't think CHECKLOCKTIMEVERIFY will make it into the next major > release though. Once headers-first and pruning is merged (which is > expected to be a matter of weeks). I'd like to split off the 0.10 > branch and give it some time to stabilize with a feature freeze, then > do a release before the end of the year. > > So 0.11, in say 6 months, would be soonest. > > Wladimir > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back <adam@cypherspace•org> wrote:
Quoted text (5 lines)
> I think you can do everything with the existing script level nlocktime > in some kind of turing completeness sense (maybe); but there is a > complexity cost that often you have to resort to extra dependent > transaction(s) (and work-around malleability until that is fully > fixed) just to get the effect.
Right, ... moreover, even with all the malleability fixes, they only work if you refrain from using certain features (e.g. cannot do an anyone-can-pay) and we cannot be completely sure all accidental vectors for malleability are gone (we've been unable to construct a proof that our strengthening of ECDSA turns it into a strong signature, though it seems likely).
Having the locktime control in a scriptPubKey sidesteps all those limitations and simplifies protocols (e.g. not requiring some three step state machine and a bunch of risky validation code to be sure a refund you receive is actually workable).
On Thu, Oct 09, 2014 at 06:28:19AM +0000, Gregory Maxwell wrote:
Quoted text (18 lines)
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back <adam@cypherspace•org> wrote: > > I think you can do everything with the existing script level nlocktime > > in some kind of turing completeness sense (maybe); but there is a > > complexity cost that often you have to resort to extra dependent > > transaction(s) (and work-around malleability until that is fully > > fixed) just to get the effect. > > Right, ... moreover, even with all the malleability fixes, they only > work if you refrain from using certain features (e.g. cannot do an > anyone-can-pay) and we cannot be completely sure all accidental > vectors for malleability are gone (we've been unable to construct a > proof that our strengthening of ECDSA turns it into a strong > signature, though it seems likely). > > Having the locktime control in a scriptPubKey sidesteps all those > limitations and simplifies protocols (e.g. not requiring some three > step state machine and a bunch of risky validation code to be sure a > refund you receive is actually workable).
Speaking of, can anyone think of an example of a complex transaction use-case that is affected by malleability which can't be fixed by CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head trying to think of a good example.
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (4 lines)
> Speaking of, can anyone think of an example of a complex transaction > use-case that is affected by malleability which can't be fixed by > CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head > trying to think of a good example.
Yea, no problem since we lack covenants.
Or a least no problem making an example, maybe you'll find it too contrived since I'm not sure what would motivate it:
You and I put 5 btc each into a kickstarter-escrow to pay Alice+some oracle that decides if alice did her job. But if a timeout expires before alice manages to get the sign off the funds must be returned completely to their original payers.
Returning them to in two outputs, one to me, one to you is trivial with a pre-signed refund.
You could make there be multiple alice outputs or refund, but then you can't guarantee an atomic reversal (e.g. maybe Alice gets half if we race).
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:
Quoted text (311 lines)
> 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 <pete@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 > 1 > ELSE > 2 > ENDIF > <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG > > At any time the funds can be spent with the following scriptSig: > > <Alice's signature> <Bob's signature> 0 > > After 3 months have passed Lenny and one of either Alice or Bob can spend the > funds with the following scriptSig: > > <Alice/Bob's signature> <Lenny's signature> 1 > > > ===Non-interactive time-locked refunds=== > > There exist a number of protocols where a transaction output is created that > the co-operation of both parties to spend the output. To ensure the failure of > one party does not result in the funds becoming lost refund transactions are > setup in advance using nLockTime. These refund transactions need to be created > interactively, and additionaly, are currently vulnerable to transaction > mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the > interactive setup with a non-interactive setup, and additionally, making > transaction mutability a non-issue. > > > ====Two-factor wallets==== > > Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's > such that one keypair is controlled by the user, and the other keypair is > controlled by the service. To spend funds the user uses locally installed > wallet software that generates one of the required signatures, and then uses a > 2nd-factor authentication method to authorize the service to create the second > SIGHASH_NONE signature that is locked until some time in the future and sends > the user that signature for storage. If the user needs to spend their funds and > the service is not available, they wait until the nLockTime expires. > > The problem is there exist numerous occasions the user will not have a valid > signature for some or all of their transaction outputs. With > CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand > scriptPubKeys of the following form are used instead: > > IF > <service pubkey> CHECKSIGVERIFY > ELSE > <expiry time> CHECKLOCKTIMEVERIFY DROP > ENDIF > <user pubkey> CHECKSIG > > Now the user is always able to spend their funds without the co-operation of > the service by waiting for the expiry time to be reached. > > > ====Micropayment Channels==== > > Jeremy Spilman style micropayment channels first setup a deposit controlled by > 2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends > the output of tx1 to payor and payee. Prior to publishing tx1 a refund > transaction is created, tx3, to ensure that should the payee vanish the payor > can get their deposit back. The process by which the refund transaction is > created is currently vulnerable to transaction mutability attacks, and > additionally, requires the payor to store the refund. Using the same > scriptPubKey from as in the Two-factor wallets example solves both these issues. > > > ===Trustless Payments for Publishing Data=== > > The PayPub protocol makes it possible to pay for information in a trustless way > by first proving that an encrypted file contains the desired data, and secondly > crafting scriptPubKeys used for payment such that spending them reveals the > encryption keys to the data. However the existing implementation has a > significant flaw: the publisher can delay the release of the keys indefinitely. > > This problem can be solved interactively with the refund transaction technique; > with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using > scriptPubKeys of the following form: > > IF > HASH160 <Hash160(encryption key)> EQUALVERIFY > <publisher pubkey> CHECKSIG > ELSE > <expiry time> CHECKLOCKTIMEVERIFY DROP > <buyer pubkey> CHECKSIG > ENDIF > > The buyer of the data is now making a secure offer with an expiry time. If the > publisher fails to accept the offer before the expiry time is reached the buyer > can cancel the offer by spending the output. > > > ===Proving sacrifice to miners' fees=== > > Proving the sacrifice of some limited resource is a common technique in a > variety of cryptographic protocols. Proving sacrifices of coins to mining fees > has been proposed as a ''universal public good'' to which the sacrifice could > be directed, rather than simply destroying the coins. However doing so is > non-trivial, and even the best existing technqiue - announce-commit sacrifices > - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to > create outputs that are provably spendable by anyone (thus to mining fees > assuming miners behave optimally and rationally) but only at a time > sufficiently far into the future that large miners profitably can't sell the > sacrifices at a discount. > > > ===Replacing the nLockTime field entirely=== > > As an aside, note how if the SignatureHash() algorithm could optionally cover > part of the scriptSig the signature could require that the scriptSig contain > CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. > (the CODESEPARATOR opcode came very close to making this possible in v0.1 of > Bitcoin) This per-signature capability could replace the per-transaction > nLockTime field entirely as a valid signature would now be the proof that a > transaction output ''can'' be spent. > > > ==Detailed Specification== > > Refer to the reference implementation, reproduced below, for the precise > semantics and detailed rationale for those semantics. > > case OP_NOP2: > { > // CHECKLOCKTIMEVERIFY > // > // (nLockTime -- nLockTime ) > > if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) > break; // not enabled; treat as a NOP > > if (stack.size() < 1) > return false; > > // Note that elsewhere numeric opcodes are limited to > // operands in the range -2**31+1 to 2**31-1, however it is > // legal for opcodes to produce results exceeding that > // range. This limitation is implemented by CScriptNum's > // default 4-byte limit. > // > // If we kept to that limit we'd have a year 2038 problem, > // even though the nLockTime field in transactions > // themselves is uint32 which only becomes meaningless > // after the year 2106. > // > // Thus as a special case we tell CScriptNum to accept up > // to 5-byte bignums, which are good until 2**32-1, the > // same limit as the nLockTime field itself. > const CScriptNum nLockTime(stacktop(-1), 5); > > // In the rare event that the argument may be < 0 due to > // some arithmetic being done first, you can always use > // 0 MAX CHECKLOCKTIMEVERIFY. > if (nLockTime < 0) > return false; > > // There are two times of nLockTime: lock-by-blockheight > // and lock-by-blocktime, distinguished by whether > // nLockTime < LOCKTIME_THRESHOLD. > // > // We want to compare apples to apples, so fail the script > // unless the type of nLockTime being tested is the same as > // the nLockTime in the transaction. > if (!( > (txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) || > (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) > )) > return false; > > // Now that we know we're comparing apples-to-apples, the > // comparison is a simple numeric one. > if (nLockTime > (int64_t)txTo.nLockTime) > return false; > > // Finally the nLockTime feature can be disabled and thus > // CHECKLOCKTIMEVERIFY bypassed if every txin has been > // finalized by setting nSequence to maxint. The > // transaction would be allowed into the blockchain, making > // the opcode ineffective. > // > // Testing if this vin is not final is sufficient to > // prevent this condition. Alternatively we could test all > // inputs, but testing just this input minimizes the data > // required to prove correct CHECKLOCKTIMEVERIFY execution. > if (txTo.vin[nIn].IsFinal()) > return false; > > break; > > } > > https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 > > > ==Upgrade and Testing Plan== > > TBD > > > ==Credits== > > Thanks goes to Gregory Maxwell for suggesting that the argument be compared > against the per-transaction nLockTime, rather than the current block height and > time. > > > ==References== > > PayPub - https://github.com/unsystem/paypub > > Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html > > > ==Copyright== > > This document is placed in the public domain. > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
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
On Mon, Mar 16, 2015 at 10:22:13PM +0000, Matt Corallo wrote:
Quoted text (6 lines)
> 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.
Quoted text (17 lines)
> 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.
Quoted text (4 lines)
> 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
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (10 lines)
> 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?
Quoted text (5 lines)
> 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.
Quoted text (6 lines)
> 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);
Quoted text (7 lines)
> 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.
Quoted text (15 lines)
> -- > '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 >
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
Quoted text (26 lines)
> 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);On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:
Quoted text (11 lines)
> On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón <jtimon@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.
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" <pete@petertodd•org> wrote:
Quoted text (32 lines)
> 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 <jtimon@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 > 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 >
On 04/21/15 07:59, Peter Todd wrote:
Quoted text (27 lines)
> 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.
Quoted text (107 lines)
>> 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 >
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.
On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
Quoted text (24 lines)
> 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).
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 <btcdrak@gmail•com> wrote:
Quoted text (34 lines)
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jtimon@jtimon•cc> 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).
>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 0xFFFFFFFF. 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 <jtimon@jtimon•cc> wrote:
Quoted text (8 lines)
> 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");
> // ...
> }
>On Tue, May 5, 2015 at 10:38 PM, Tier Nolan <tier.nolan@gmail•com> wrote:
Quoted text (3 lines)
> 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.
Quoted text (7 lines)
> There should be an exception for final inputs. Otherwise, they will count > as relative locktime of 0xFFFFFFFF. 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 0xFFFFFFFF for the tx to be final.
Quoted text (5 lines)
> 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.
Yes.
Quoted text (3 lines)
> 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.
Quoted text (7 lines)
> 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.
Quoted text (20 lines)
> 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.
Quoted text (24 lines)
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jtimon@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
>On Wed, May 6, 2015 at 8:37 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
Quoted text (3 lines)
> > 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.