summaryrefslogtreecommitdiff
path: root/8a/4e6051245072721d0d7426981a42d1d6cda568
blob: 94fcee917108e03e34138abcda63959349b269ee (plain)
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
77
78
79
80
81
82
83
84
85
86
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jtimon@jtimon.cc>) id 1YpEUV-0004ca-Ov
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 May 2015 11:24:51 +0000
Received: from mail-wg0-f50.google.com ([74.125.82.50])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YpEUU-0001Xn-K5
	for bitcoin-development@lists.sourceforge.net;
	Mon, 04 May 2015 11:24:51 +0000
Received: by wgso17 with SMTP id o17so146823218wgs.1
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 04 May 2015 04:24:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=mStEpuqVG/pzlrApd4S/qgwa4RH57iKHeNRgeFg2i/4=;
	b=GwCn1U8H7dvuJW5Yykny4c3ukZoZMWVeODkgh4Ijjs5q1o3amoYYEKqg4NZhtSiiIr
	hvuQDZrB+RCVOhjwkKpzvtkvORYGUnDTgkKiFpEHoB/KwZ5d2sldMh+gHP1oUmSaXbRV
	+kVWGSUKJCiNy74hfS8p3w1vQ1687Kvnxvs3qtDT1zNJ63Cst2hyCDwJmhun9QyYyKua
	jv1vpojTBDWvWc60ZDjZoA7O114x+CIZyu4B2nrCi873c3R4IMtY58cPDaKPjPpu/XzB
	vv9S/uViH60kVjFzhZ5eHuJy40k7OjAd1KIj5xjmUp102iFjaqSQS2Hmd6n5HdF0mrbw
	PJNQ==
X-Gm-Message-State: ALoCoQlxyvkqH3IIT1/uGJn5qEh5RddEV7eRYXPmqUlsXUppV1qT80lqrvzEb+DkqAJc2xfF57Jp
MIME-Version: 1.0
X-Received: by 10.194.92.137 with SMTP id cm9mr41404948wjb.133.1430738684419; 
	Mon, 04 May 2015 04:24:44 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Mon, 4 May 2015 04:24:44 -0700 (PDT)
In-Reply-To: <5546D653.4070404@bluematt.me>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
	<5546D653.4070404@bluematt.me>
Date: Mon, 4 May 2015 13:24:44 +0200
Message-ID: <CABm2gDqcD4ENex3LzKfeGqaotoO-XxLHhLzOEPwk92SaiD8snQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YpEUU-0001Xn-K5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
	proposal)
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: Mon, 04 May 2015 11:24:51 -0000

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.