Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 192.3.11.21 as permitted sender)
	client-ip=192.3.11.21; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 1 Oct 2014 18:23:55 +0000
User-Agent: KMail/1.13.7 (Linux/3.15.5-gentoo; KDE/4.12.5; x86_64; ; )
References: <20141001130826.GM28710@savin.petertodd.org>
In-Reply-To: <20141001130826.GM28710@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201410011823.56441.luke@dashjr.org>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
	a txout from being spent until an expiration time
Precedence: list

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