1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1XZOZK-00057n-0L
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Oct 2014 18:24:06 +0000
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;
Received: from zinan.dashjr.org ([192.3.11.21])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XZOZJ-0006rs-52 for bitcoin-development@lists.sourceforge.net;
Wed, 01 Oct 2014 18:24:05 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:be5f:f4ff:febf:4f76])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id A4B9E1080849
for <bitcoin-development@lists.sourceforge.net>;
Wed, 1 Oct 2014 18:23:58 +0000 (UTC)
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>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201410011823.56441.luke@dashjr.org>
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1XZOZJ-0006rs-52
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
a txout from being spent until an expiration time
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2014 18:24:06 -0000
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
|
