* [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
@ 2014-10-01 13:08 Peter Todd
2014-10-01 15:01 ` Gavin Andresen
` (3 more replies)
0 siblings, 4 replies; 46+ messages in thread
From: Peter Todd @ 2014-10-01 13:08 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 12193 bytes --]
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.
--
'peter'[:-1]@petertodd.org
000000000000000009012f16fe9db21abbba5025453a9b7b589a807b21cec318
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
@ 2014-10-01 15:01 ` Gavin Andresen
2014-10-02 1:06 ` Peter Todd
2014-10-01 15:29 ` Sergio Lerner
` (2 subsequent siblings)
3 siblings, 1 reply; 46+ messages in thread
From: Gavin Andresen @ 2014-10-01 15:01 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
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.....
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 829 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
2014-10-01 15:01 ` Gavin Andresen
@ 2014-10-01 15:29 ` Sergio Lerner
2014-10-01 17:06 ` Peter Todd
2014-10-01 18:23 ` Luke Dashjr
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
3 siblings, 1 reply; 46+ messages in thread
From: Sergio Lerner @ 2014-10-01 15:29 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 15:29 ` Sergio Lerner
@ 2014-10-01 17:06 ` Peter Todd
0 siblings, 0 replies; 46+ messages in thread
From: Peter Todd @ 2014-10-01 17:06 UTC (permalink / raw)
To: Sergio Lerner, bitcoin-development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:
>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
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJULDR7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhS8ACADKQYHqOvmKJBYv+ZZM
Vs6358sMEtHGIEoTEjPio/vGbM0TkCGvRAnvzXDYz20WQcQsWZ4jflP1BihdbszE
NrQ+4JYm11Sw6vK5RpxeI4rJSb/hMUJooR0WQn8TOSZowtVxhINUnBku+N21Dhuf
IBCzji5bW2wjeN50psWOjJkBo1gZP761tjfmpI9kdNFe6RYIceAIWIIhccKX4PhA
FucuPawjB8+Ajd707UGHew82VHbXis+6Oxzob7hVJRH/wNKpkR6LXRxh2dwVaRAw
/Eytbt8LZRcRZGNXvMZ4GKG0xP79cBQI30QhrgM88gGyioMxrWcP2hVhtADOVl40
E4yh
=C9fu
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
2014-10-01 15:01 ` Gavin Andresen
2014-10-01 15:29 ` Sergio Lerner
@ 2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
2014-10-02 0:05 ` Peter Todd
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
3 siblings, 2 replies; 46+ messages in thread
From: Luke Dashjr @ 2014-10-01 18:23 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 18:23 ` Luke Dashjr
@ 2014-10-01 20:58 ` Gavin Andresen
2014-10-01 21:04 ` Alan Reiner
2014-10-02 0:05 ` Peter Todd
1 sibling, 1 reply; 46+ messages in thread
From: Gavin Andresen @ 2014-10-01 20:58 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr <luke@dashjr•org> wrote:
> 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).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1048 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 20:58 ` Gavin Andresen
@ 2014-10-01 21:04 ` Alan Reiner
2014-10-01 21:34 ` Gavin Andresen
0 siblings, 1 reply; 46+ messages in thread
From: Alan Reiner @ 2014-10-01 21:04 UTC (permalink / raw)
To: bitcoin-development
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?
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 21:04 ` Alan Reiner
@ 2014-10-01 21:34 ` Gavin Andresen
2014-10-02 0:12 ` Peter Todd
0 siblings, 1 reply; 46+ messages in thread
From: Gavin Andresen @ 2014-10-01 21:34 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> 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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1364 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
@ 2014-10-02 0:05 ` Peter Todd
2014-10-02 0:55 ` Luke Dashjr
1 sibling, 1 reply; 46+ messages in thread
From: Peter Todd @ 2014-10-02 0:05 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJULJa7MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYlFB/4r2Hv82RK85BDe+hAT
ZQJtzXv1JRCa+o7Y344unMJ8y7rSDJRFSH+X+4VeCln833XKb8FNgj2loniQAq5H
FIH04gPf7yuXvDrKI6HwCj9Q3KLPv4UZM1+LjijczOM/y4e/C82squpTpgFaton+
6VXU/WyaCDYDS4he975E14YhBBVhoadZZMOW3Moxgpnde2RwAYZdkcdhqvh/3dJC
/9VOEUBu0ENyraL5HHGdZyjSJT2MsY4CBTCCd54RxBBMoMZqFRvIi4Xrt2vE1T+Y
R2DtKs7upjydnfg9KPm484upvO2U3lcnPBW9rqOVQyV2q81TcloRtUIU4QQ9GCAk
ayj2
=p0BG
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 21:34 ` Gavin Andresen
@ 2014-10-02 0:12 ` Peter Todd
0 siblings, 0 replies; 46+ messages in thread
From: Peter Todd @ 2014-10-02 0:12 UTC (permalink / raw)
To: Gavin Andresen, Alan Reiner; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen <gavinandresen@gmail•com> wrote:
>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.
>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.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJULJiDMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTwKCACD+GWzID7Qhn2no1p9
KYNiYlQVNt+DPZY0QB7MujL8riAmyJBliF9zptfjEdvglShoIzonJien/DOCjp9S
Lw2wMvPhtZGgSttJEvlr3wclty6TfWygd4Y+v/MR8TnYC99su7HhiQ1pkqohkklv
RxeF9jXhcJMERzN6wPUyeowfziBAfbWw+M5CwiXRlzLLBWO37eoDTXzUD0Np5Nia
nFxQ7sAsSbLijVpvigh9uIi3/1347VqwMc+0ZsZoZ2AnMICA8Q+XKNHv7DKpChxw
Xa+P532Di34uu8dlG/Z/UwYdENvb15P1yUZ7CEDfqNqrZp0RM7x+XKMA7QPwhuz3
YSBp
=mvKP
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-02 0:05 ` Peter Todd
@ 2014-10-02 0:55 ` Luke Dashjr
2014-10-02 1:09 ` Peter Todd
0 siblings, 1 reply; 46+ messages in thread
From: Luke Dashjr @ 2014-10-02 0:55 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
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.
> > 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-01 15:01 ` Gavin Andresen
@ 2014-10-02 1:06 ` Peter Todd
0 siblings, 0 replies; 46+ messages in thread
From: Peter Todd @ 2014-10-02 1:06 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen <gavinandresen@gmail•com> wrote:
>Very nice, semantics are clear and use cases are compelling.
Thanks!
>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.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJULKT9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhevAB/0eTWleef5GehrH03tZ
NrOdtJ881NhXJpB3p81jPyT9z4gv9u3M5bkjMOvClQaf8PX551ICgKbWDQTNf9oS
TF/blkqWRWX28VLkNsMUQNN/dd7rdqDMpnwcN8worgHToRMa4drFBU/MXapedMLQ
Sb2ETXGYPm4b/HqgFf9j/EGt8jhmnk4HiSwZ6wdhdYLbbZ6NhplSR8tTs+GouAWp
PHntN6DQI8oFDaIKkMbs2dDlpXSGG9hxr6m46LBwp/CHBY9aKkwLyaJXkMVovP3J
HrSYTzlCmjrDNbLJwIze+fyO2UDkgZUzjVENfMvixcQNdz0pVoCzJ2BK8b4fAc7Y
maRA
=Mz3E
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-02 0:55 ` Luke Dashjr
@ 2014-10-02 1:09 ` Peter Todd
2014-10-02 15:05 ` Flavien Charlon
0 siblings, 1 reply; 46+ messages in thread
From: Peter Todd @ 2014-10-02 1:09 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-development
-----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-----
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-02 1:09 ` Peter Todd
@ 2014-10-02 15:05 ` Flavien Charlon
2014-10-03 14:28 ` Matt Whitlock
0 siblings, 1 reply; 46+ messages in thread
From: Flavien Charlon @ 2014-10-02 15:05 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4038 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-02 15:05 ` Flavien Charlon
@ 2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Matt Whitlock @ 2014-10-03 14:28 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development, Flavien Charlon
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
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 14:28 ` Matt Whitlock
@ 2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2 siblings, 0 replies; 46+ messages in thread
From: Matt Whitlock @ 2014-10-03 14:30 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development, Flavien Charlon
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:
> 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
> > >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
@ 2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2 siblings, 0 replies; 46+ messages in thread
From: Gregory Maxwell @ 2014-10-03 16:17 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Development, Flavien Charlon
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> 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.
> 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).
> 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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
@ 2014-10-03 17:50 ` Luke Dashjr
2014-10-03 20:58 ` Mike Hearn
2 siblings, 1 reply; 46+ messages in thread
From: Luke Dashjr @ 2014-10-03 17:50 UTC (permalink / raw)
To: bitcoin-development; +Cc: Flavien Charlon
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
> 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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 17:50 ` Luke Dashjr
@ 2014-10-03 20:58 ` Mike Hearn
2014-10-03 23:12 ` Jeff Garzik
0 siblings, 1 reply; 46+ messages in thread
From: Mike Hearn @ 2014-10-03 20:58 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev, Flavien Charlon
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2985 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 20:58 ` Mike Hearn
@ 2014-10-03 23:12 ` Jeff Garzik
2014-10-04 0:38 ` Peter Todd
0 siblings, 1 reply; 46+ messages in thread
From: Jeff Garzik @ 2014-10-03 23:12 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Flavien Charlon
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:
> 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
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-03 23:12 ` Jeff Garzik
@ 2014-10-04 0:38 ` Peter Todd
2014-10-04 12:58 ` Mike Hearn
0 siblings, 1 reply; 46+ messages in thread
From: Peter Todd @ 2014-10-04 0:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev, Flavien Charlon
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Fri, Oct 03, 2014 at 07:12:11PM -0400, Jeff Garzik wrote:
> 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.
--
'peter'[:-1]@petertodd.org
000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-04 0:38 ` Peter Todd
@ 2014-10-04 12:58 ` Mike Hearn
2014-10-07 15:50 ` Gavin Andresen
0 siblings, 1 reply; 46+ messages in thread
From: Mike Hearn @ 2014-10-04 12:58 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev, Flavien Charlon
[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 1666 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-04 12:58 ` Mike Hearn
@ 2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
2014-10-08 4:07 ` Tom Harding
0 siblings, 2 replies; 46+ messages in thread
From: Gavin Andresen @ 2014-10-07 15:50 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Flavien Charlon
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn <mike@plan99•net> wrote:
>
>> 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.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1298 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-07 15:50 ` Gavin Andresen
@ 2014-10-07 16:08 ` Mike Hearn
2014-10-08 10:26 ` Wladimir
2014-10-08 4:07 ` Tom Harding
1 sibling, 1 reply; 46+ messages in thread
From: Mike Hearn @ 2014-10-07 16:08 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev, Flavien Charlon
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
>
> 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
> 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.
[-- Attachment #2: Type: text/html, Size: 2765 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
@ 2014-10-08 4:07 ` Tom Harding
2014-10-08 10:15 ` Mike Hearn
1 sibling, 1 reply; 46+ messages in thread
From: Tom Harding @ 2014-10-08 4:07 UTC (permalink / raw)
To: bitcoin-development
On 10/7/2014 8:50 AM, Gavin Andresen wrote:
>
> 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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-08 4:07 ` Tom Harding
@ 2014-10-08 10:15 ` Mike Hearn
0 siblings, 0 replies; 46+ messages in thread
From: Mike Hearn @ 2014-10-08 10:15 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 791 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-07 16:08 ` Mike Hearn
@ 2014-10-08 10:26 ` Wladimir
2014-10-09 3:13 ` Alan Reiner
0 siblings, 1 reply; 46+ messages in thread
From: Wladimir @ 2014-10-08 10:26 UTC (permalink / raw)
To: Mike Hearn; +Cc: Flavien Charlon, Bitcoin Dev
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-08 10:26 ` Wladimir
@ 2014-10-09 3:13 ` Alan Reiner
2014-10-09 6:14 ` Adam Back
0 siblings, 1 reply; 46+ messages in thread
From: Alan Reiner @ 2014-10-09 3:13 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4480 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-09 3:13 ` Alan Reiner
@ 2014-10-09 6:14 ` Adam Back
2014-10-09 6:28 ` Gregory Maxwell
0 siblings, 1 reply; 46+ messages in thread
From: Adam Back @ 2014-10-09 6:14 UTC (permalink / raw)
To: Alan Reiner; +Cc: Bitcoin Dev
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:
> 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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-09 6:14 ` Adam Back
@ 2014-10-09 6:28 ` Gregory Maxwell
2014-10-09 6:33 ` Peter Todd
0 siblings, 1 reply; 46+ messages in thread
From: Gregory Maxwell @ 2014-10-09 6:28 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin Dev
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).
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-09 6:28 ` Gregory Maxwell
@ 2014-10-09 6:33 ` Peter Todd
2014-10-09 6:40 ` Gregory Maxwell
0 siblings, 1 reply; 46+ messages in thread
From: Peter Todd @ 2014-10-09 6:33 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
On Thu, Oct 09, 2014 at 06:28:19AM +0000, Gregory Maxwell wrote:
> 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.
--
'peter'[:-1]@petertodd.org
000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
2014-10-09 6:33 ` Peter Todd
@ 2014-10-09 6:40 ` Gregory Maxwell
0 siblings, 0 replies; 46+ messages in thread
From: Gregory Maxwell @ 2014-10-09 6:40 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd <pete@petertodd•org> wrote:
> 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).
^ permalink raw reply [flat|nested] 46+ messages in thread
* [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
` (2 preceding siblings ...)
2014-10-01 18:23 ` Luke Dashjr
@ 2015-03-16 22:22 ` Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
3 siblings, 2 replies; 46+ messages in thread
From: Matt Corallo @ 2015-03-16 22:22 UTC (permalink / raw)
To: bitcoin-development
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the height of the output being spent and then has
identical semantics to CLTV.
A slightly different API (and different name) was described by maaku at
http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
which does a better job of saving softfork-available opcode space.
There are two major drawbacks to adding such an operation, however.
1) More transaction information is exposed inside the script (prior to
CLTV we only had the sigchecking operation exposed, with a CLTV and
RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
2) Bitcoin Core's mempool invariant of "all transactions in the mempool
could be thrown into one overside block and aside from block size, it
would be valid" becomes harder to enforce. Currently, during reorgs,
coinbase spends need checked (specifically, anything spending THE
coinbase 100 blocks ago needs checked) and locktime transactions need
checked. With such a new operation, any script which used this new
opcode during its execution would need to be re-evaluated during reorgs.
I think both of these requirements are reasonable and not particularly
cumbersome, and the value of such an operation is quite nice for some
protocols (including settings setting up a contest interval in a
sidechain data validation operation).
Thoughts?
Matt
On 10/01/14 13:08, Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
>
> https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
>
> The reference implementation, including a full-set of unittests for the
> opcode semantics can be found at:
>
> https://github.com/petertodd/bitcoin/compare/checklocktimeverify
>
> <pre>
> BIP:
> Title: OP_CHECKLOCKTIMEVERIFY
> Author: Peter Todd <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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
@ 2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
1 sibling, 0 replies; 46+ messages in thread
From: Zooko Wilcox-OHearn @ 2015-03-19 17:39 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
@ 2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo
1 sibling, 2 replies; 46+ messages in thread
From: Peter Todd @ 2015-04-21 7:59 UTC (permalink / raw)
To: Matt Corallo; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 5986 bytes --]
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.
> 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
--
'peter'[:-1]@petertodd.org
0000000000000000015e09479548c5b63b99a62d31b019e6479f195bf0cbd935
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-04-21 7:59 ` Peter Todd
@ 2015-04-26 11:35 ` Jorge Timón
2015-04-26 12:20 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo
1 sibling, 1 reply; 46+ messages in thread
From: Jorge Timón @ 2015-04-26 11:35 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd <pete@petertodd•org> wrote:
> Thus we have a few possibilities:
>
> 1) RCLTV against nLockTime
>
> Needs a minimum age > COINBASE_MATURITY to be safe.
>
>
> 2) RCLTV against current block height/time
>
> Completely reorg safe.
Yes, can we call this one OP_MATURITY to distinguish it from RCLTV?
> 3) GET_TXOUT_HEIGHT/TIME <diff> ADD CLTV
>
> To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age <
> COINBASE_MATURITY. This can be implemented by comparing against
> nLockTime.
Mhmm, interesting.
> All three possibilities require us to make information about the
> prevout's height/time available to VerifyScript(). The only question is
> if we want VerifyScript() to also take the current block height/time - I
> see no reason why it can't. As for the mempool, keeping track of what
> transactions made use of these opcodes so they can be reevaluated if
> their prevouts are re-organised seems fine to me.
I'm totally fine with changing the interface to:
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, unsigned nHeight,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
I prefer op_maturity over RCLTV and there are also gains for absolute
CLTV as you explain later.
When you validate the script inputs of a transaction you already have
a height, either the real final nHeight in ConnectBlock and the miner,
or nSpendHeight in AcceptToMemoryPool.
The costs are meaningless in my opinion, specially when we will
already have to change the interface to add libsecp256k1's context.
I'm infinitely more worried about the other assumption that the 3
solutions are already making.
Changing to
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, const CCoinsViewCache& inputs,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
Is simply not possible because CCoinsViewCache is a C++.
You could solve it in a similar way in which you could solve that
dependency for VerifyTransaction.
For example:
typedef const CTxOut& (*TxOutputGetter)(const uint256& txid, uint32_t n);
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, TxOutputGetter utxoGetter,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
Of course, this is assuming that CTxOut becomes a C struct instead of
a C++ class and little things like that.
In terms of code encapsulation, this is still 100 times uglier than
adding the nHeight so if we're doing it, yes, please, let's do both.
There's another possibility that could keep the utxo out of Script verification:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nSequence;
}
could turn into:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nHeight;
}
And a new softfork rule could enforce that all new CTxIn set nHeight
to the correct height in which its corresponding prevout got into the
chain.
That would remove the need for the TxOutputGetter param in
bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
(apart from other ugly implementation details).
So, in summary, I think the new interface has to be something along these lines:
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo,
unsigned int nIn,
unsigned int txToLen,
TxOutputGetter utxoGetter, unsigned nHeight, secp256k1_context_t *ctx
unsigned int flags,
bitcoinconsensus_error* err);
> Time-based locks
> ================
>
> Do we want to support them at all? May cause incentive issues with
> mining, see #bitcoin-wizards discussion, Jul 17th 2013:
>
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-17.log
I'm totally fine not supporting time-based locks for the new operators.
Removing them from the regular nLockTime could be more complicated but
I wouldn't mind either.
Every time I think of a contract or protocol that involves time, I do
it in terms of block heights.
I would prefer to change all my clocks to work in blocks instead of
minutes over changing nHeights for timestamps in any of those
contracts.
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000015e09479548c5b63b99a62d31b019e6479f195bf0cbd935
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-04-26 11:35 ` Jorge Timón
@ 2015-04-26 12:20 ` Jorge Timón
2015-04-27 19:35 ` Peter Todd
0 siblings, 1 reply; 46+ messages in thread
From: Jorge Timón @ 2015-04-26 12:20 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> There's another possibility that could keep the utxo out of Script verification:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nSequence;
> }
>
> could turn into:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nHeight;
> }
>
> And a new softfork rule could enforce that all new CTxIn set nHeight
> to the correct height in which its corresponding prevout got into the
> chain.
> That would remove the need for the TxOutputGetter param in
> bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
> (apart from other ugly implementation details).
Wait, wait, this can be made reorg-safe and more backards compatible.
The new validation rule at the tx validation level (currently in
main::CheckInputs()) would be
for (unsigned int i = 0; i < tx.vin.size(); i++) {
// ...
if (tx.vin.nHeight + 100 > tx.nLockTime)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-reorg-unsafe");
if (coins->nHeight > tx.vin.nHeight)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-false");
// ...
}
Existing transactions that have used the deprecated CTxIn::nSequence
for something else will be fine if they've used low nSequences.
The only concern would be breaking some colored coins kernels, but
there's many others implemented that don't rely on CTxIn::nSequence.
Transactions that want to use OP_MATURITY just have to set the
corresponding CTxIn::nHeight and CTransaction::nLockTime properly.
This way op_maturity wouldn't require anything from the utxo and the
final interface could be:
int bitcoinconsensus_verify_script(const unsigned char* scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char* txTo,
unsigned int txToLen,
unsigned int nIn, unsigned int nHeight,
unsigned int flags,
secp256k1_context_t* ctx,
bitcoinconsensus_error* err);
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-04-26 12:20 ` Jorge Timón
@ 2015-04-27 19:35 ` Peter Todd
2015-04-28 7:44 ` Jorge Timón
0 siblings, 1 reply; 46+ messages in thread
From: Peter Todd @ 2015-04-27 19:35 UTC (permalink / raw)
To: Jorge Timón, Pieter Wuille; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-04-27 19:35 ` Peter Todd
@ 2015-04-28 7:44 ` Jorge Timón
0 siblings, 0 replies; 46+ messages in thread
From: Jorge Timón @ 2015-04-28 7:44 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
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:
> 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
>
[-- Attachment #2: Type: text/html, Size: 2796 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
@ 2015-05-04 2:15 ` Matt Corallo
2015-05-04 11:24 ` Jorge Timón
1 sibling, 1 reply; 46+ messages in thread
From: Matt Corallo @ 2015-05-04 2:15 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-development
On 04/21/15 07:59, Peter Todd wrote:
> On Mon, Mar 16, 2015 at 10:22:13PM +0000, Matt Corallo wrote:
>> In building some CLTV-based contracts, it is often also useful to have a
>> method of requiring, instead of locktime-is-at-least-N,
>> locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
>> an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
>> stack element, adds the height of the output being spent and then has
>> identical semantics to CLTV.
>
> Depending on what you mean by "identical" this isn't actually reorg
> safe. For instance consider this implementation:
>
> nLockTime = stack[-1] + prevout.nHeight
> if (nLockTime > txTo.nLockTime):
> return False
>
> Used with this scriptPubKey:
>
> 10 RCLTV DROP <pubkey> CHECKSIG
>
> If I create that output in tx1 which is mined at height 42 I can spend
> it in a tx2 at height > 42+10 by setting tx2's nLockTime to >42+10, for
> instance 53. However if a reorg happens and tx1 ends up at height 43
> after the reorg I'm stuck - tx2's nLockTime is set at 42.
>
> Thus RCTLV is only reorg safe if the height is compared against the
> actual block height of the block containing the spending transaction,
> not the spending transaction's nLockTime.
Yes, as discussed on IRC months ago when the first email was sent, the
assumption is that you would require N be at least 100. That way you are
reorg safe up to the same limit as coinbase transactions, which are also
only reorg safe in the case of no 100-block reorgs. Its not ideal in
some contracts, but keeping the no-second-nLockTime-equivalent property
is worth it IMO, and its still incredibly useful in many contracts.
>> A slightly different API (and different name) was described by maaku at
>> http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
>> which does a better job of saving softfork-available opcode space.
>>
>> There are two major drawbacks to adding such an operation, however.
>>
>> 1) More transaction information is exposed inside the script (prior to
>> CLTV we only had the sigchecking operation exposed, with a CLTV and
>> RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
>>
>> 2) Bitcoin Core's mempool invariant of "all transactions in the mempool
>> could be thrown into one overside block and aside from block size, it
>> would be valid" becomes harder to enforce. Currently, during reorgs,
>> coinbase spends need checked (specifically, anything spending THE
>> coinbase 100 blocks ago needs checked) and locktime transactions need
>> checked. With such a new operation, any script which used this new
>> opcode during its execution would need to be re-evaluated during reorgs.
>
> Yup, definitely kinda ugly.
>
> If the above style of RCTLV was used, one possibility might be to make
> the relative locktime difference be required to be at least 100 blocks,
> same as the coinbase maturity, and just accept that it's probably not
> going to cause any problems, but could in an extremely big reorg. But
> re-orgs that big might be big enough that we're screwed anyway...
>
> With the 100 block rule, during a sufficiently large reorg that
> coinbases become unavailble, simply disconnect entire blocks - all
> txouts created by them.
>
>> I think both of these requirements are reasonable and not particularly
>> cumbersome, and the value of such an operation is quite nice for some
>> protocols (including settings setting up a contest interval in a
>> sidechain data validation operation).
>
> So to be clear, right now the minimal interface to script execution is
> simply:
>
> int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, unsigned int scriptPubKeyLen,
> const unsigned char *txTo , unsigned int txToLen,
> unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err);
>
> Where scriptPubKey is derived from the unspent coin in the UTXO set and
> txTo is the transaction containing the script that is being executed.
> The UTXO set itself currently contains CCoins entries, one for each
> transaction with unspent outputs, which basically contain:
>
> nVersion - tx nVersion
> nHeight - Height of the block the transaction is contained in.
> vout - Unspent CTxOut's of the transaction.
>
> The block nTime isn't directly available through the UTXO set, although
> it can be found in the block headers. This does require nodes to have
> the block headers, but at 4MB/year growth it's reasonable to assume the
> UTXO set will grow faster.
>
> Script execution does not have direct access to the current block
> height/block time, however it does have indirect access via nLockTime.
>
> Thus we have a few possibilities:
>
> 1) RCLTV against nLockTime
>
> Needs a minimum age > COINBASE_MATURITY to be safe.
>
>
> 2) RCLTV against current block height/time
>
> Completely reorg safe.
>
>
> 3) GET_TXOUT_HEIGHT/TIME <diff> ADD CLTV
>
> To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age <
> COINBASE_MATURITY. This can be implemented by comparing against
> nLockTime.
>
>
> All three possibilities require us to make information about the
> prevout's height/time available to VerifyScript(). The only question is
> if we want VerifyScript() to also take the current block height/time - I
> see no reason why it can't. As for the mempool, keeping track of what
> transactions made use of these opcodes so they can be reevaluated if
> their prevouts are re-organised seems fine to me.
>
>
> Absolute CLTV
> =============
>
> If we are going to make the block height/time available to
> VerifyScript() to implement RCLTV, should absolute CLTV should continue
> to have the proposed behavior of checking against nLockTime? If we go
> with RCLTV against current block height/time, I'm going to vote no,
> because doing so needlessly limits it to only being able to compare
> against a block height or a block time in a single transaction.
> Similarly it can complicate multi-party signatures in some
> circumstances, as all parties must agree on a common nLockTime.
>
>
> Time-based locks
> ================
>
> Do we want to support them at all? May cause incentive issues with
> mining, see #bitcoin-wizards discussion, Jul 17th 2013:
>
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-17.log
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-04 2:15 ` Matt Corallo
@ 2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
2015-05-05 20:38 ` Tier Nolan
0 siblings, 2 replies; 46+ messages in thread
From: Jorge Timón @ 2015-05-04 11:24 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-04 11:24 ` Jorge Timón
@ 2015-05-05 0:41 ` Btc Drak
2015-05-05 19:19 ` Jorge Timón
2015-05-05 20:38 ` Tier Nolan
1 sibling, 1 reply; 46+ messages in thread
From: Btc Drak @ 2015-05-05 0:41 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
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).
[-- Attachment #2: Type: text/html, Size: 1772 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-05 0:41 ` Btc Drak
@ 2015-05-05 19:19 ` Jorge Timón
0 siblings, 0 replies; 46+ messages in thread
From: Jorge Timón @ 2015-05-05 19:19 UTC (permalink / raw)
To: Btc Drak, Mark Friedenbach; +Cc: Bitcoin Dev
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:
> 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).
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
@ 2015-05-05 20:38 ` Tier Nolan
2015-05-06 7:37 ` Jorge Timón
1 sibling, 1 reply; 46+ messages in thread
From: Tier Nolan @ 2015-05-05 20:38 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
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:
> 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");
> // ...
> }
>
[-- Attachment #2: Type: text/html, Size: 3502 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-05 20:38 ` Tier Nolan
@ 2015-05-06 7:37 ` Jorge Timón
2015-05-06 22:09 ` Tier Nolan
0 siblings, 1 reply; 46+ messages in thread
From: Jorge Timón @ 2015-05-06 7:37 UTC (permalink / raw)
To: Tier Nolan; +Cc: Bitcoin Dev
On Tue, May 5, 2015 at 10:38 PM, Tier Nolan <tier.nolan@gmail•com> wrote:
> I think that should be greater than in the comparison? You want it to fail
> if the the height of the UTXO plus the sequence number is greater than the
> spending block's height.
Yes, sorry, I changed it just before sending from "what needs to be
satisfied for the validation error to trigger" to "what needs to be
satisfied for the tx to be valid".
You're right.
> There should be an exception for final inputs. Otherwise, they will count
> as relative locktime of 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.
> 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.
> It does make sequence mean something completely different from before.
> Invalidating previously valid transactions has the potential to reduce
> confidence in the currency.
Well, the semantics of nSequence don't really change completely. In
fact, one could argue that this put it closer to its original
semantics.
But in any case, yes, already signed transaction should remain valid.
No transaction would become invalid, just non-final.
As soon as the height of its inputs plus their respective nSquences
get higher than current height they will become final again.
I cannot think of any use case where a tx becomes invalid forever.
Also, probably most people have usedrelatively low values for
nSequence given the original semantics, just like the relative lock
nSquence will likely be used as well.
> A workaround would be to have a way to enable it in the sigScript by
> extending Peter Todd's suggestion in the other email chain.
>
> <1> OP_NOP2 means OP_CHECKLOCKTIMEVERIFY (absolute)
> <2> OP_NOP2 means OP_RELATIVECHECKLOCKTIMEVERIFY
>
> <3> OP_NOP2 means OP_SEQUENCE_AS_RELATIVE_HEIGHT
To be clear, this proposal is supposed to replace RCLTV, so there
would still be 2 options. But please let's imagine we have infinite
opcodes in this thread and let the "should we design an uglier
scripting langues to save opcodes?" question in the other one.
> OP_SEQUENCE_AS_RELATIVE_HEIGHT would cause the script to fail unless it was
> the first opcode in the script. It acts as a flag to enable using the
> sequence number as for relative block height.
>
> This can be achieved using a simple pattern match.
>
> bool CScript::IsSequenceAsRelativeHeight() const
> {
> // Extra-fast test for pay-to-script-hash CScripts:
> return (this->size() >= 4 &&
> this->at(0) == OP_PUSHDATA1 &&
> this->at(1) == 1 &&
> this->at(2) == 0xFF &&
> this->at(3) == OP_NOP2);
> }
>
> if (!tx.vin[i].IsFinal() && tx.vin[i].scriptSig.IsSequenceAsRelativeHeight()
> && nSpendHeight < coins->nHeight + tx.vin[i].nSequence)
> return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <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
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
2015-05-06 7:37 ` Jorge Timón
@ 2015-05-06 22:09 ` Tier Nolan
0 siblings, 0 replies; 46+ messages in thread
From: Tier Nolan @ 2015-05-06 22:09 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
> This gives you less flexibility and I don't think it's necessary.
> Please let's try to avoid this if it's possible.
It is just a switch that turns on and off the new mode.
In retrospect, it would be better to just up the transaction version.
In transactions from v2 onwards, the sequence field means height. That
means legacy transactions would be spendable.
This is a pure soft-fork.
[-- Attachment #2: Type: text/html, Size: 866 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2015-05-06 22:10 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-01 13:08 [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time Peter Todd
2014-10-01 15:01 ` Gavin Andresen
2014-10-02 1:06 ` Peter Todd
2014-10-01 15:29 ` Sergio Lerner
2014-10-01 17:06 ` Peter Todd
2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
2014-10-01 21:04 ` Alan Reiner
2014-10-01 21:34 ` Gavin Andresen
2014-10-02 0:12 ` Peter Todd
2014-10-02 0:05 ` Peter Todd
2014-10-02 0:55 ` Luke Dashjr
2014-10-02 1:09 ` Peter Todd
2014-10-02 15:05 ` Flavien Charlon
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2014-10-03 20:58 ` Mike Hearn
2014-10-03 23:12 ` Jeff Garzik
2014-10-04 0:38 ` Peter Todd
2014-10-04 12:58 ` Mike Hearn
2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
2014-10-08 10:26 ` Wladimir
2014-10-09 3:13 ` Alan Reiner
2014-10-09 6:14 ` Adam Back
2014-10-09 6:28 ` Gregory Maxwell
2014-10-09 6:33 ` Peter Todd
2014-10-09 6:40 ` Gregory Maxwell
2014-10-08 4:07 ` Tom Harding
2014-10-08 10:15 ` Mike Hearn
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
2015-04-26 12:20 ` Jorge Timón
2015-04-27 19:35 ` Peter Todd
2015-04-28 7:44 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo
2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
2015-05-05 19:19 ` Jorge Timón
2015-05-05 20:38 ` Tier Nolan
2015-05-06 7:37 ` Jorge Timón
2015-05-06 22:09 ` Tier Nolan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox