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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1Y0ZjL-0005if-3k
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 17:46:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.178 as permitted sender)
client-ip=209.85.213.178; envelope-from=laanwj@gmail.com;
helo=mail-ig0-f178.google.com;
Received: from mail-ig0-f178.google.com ([209.85.213.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y0ZjK-0001JN-FM
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Dec 2014 17:46:47 +0000
Received: by mail-ig0-f178.google.com with SMTP id hl2so5516021igb.11
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Dec 2014 09:46:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.156.67 with SMTP id f64mr10233467ioe.9.1418665601235;
Mon, 15 Dec 2014 09:46:41 -0800 (PST)
Received: by 10.64.195.225 with HTTP; Mon, 15 Dec 2014 09:46:41 -0800 (PST)
In-Reply-To: <20141215124730.GA8321@savin.petertodd.org>
References: <20141215124730.GA8321@savin.petertodd.org>
Date: Mon, 15 Dec 2014 17:46:41 +0000
Message-ID: <CA+s+GJAYC8SJ2wOTfhATfzemV+Qb3CarOQotHrzmx5JE+q2iLQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Y0ZjK-0001JN-FM
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean
CHECKLOCKTIMEVERIFY can't be merged
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, 15 Dec 2014 17:46:47 -0000
> While it would be nice to have a library encapsulating the consensus code, this
> shouldn't come at the cost of safety, especially when the actual users of that
> library or their needs is still uncertain.
While I agree that it shouldn't come at unreasonable risk, my whole
reason for prioritizing the consensus library is that it is the first
step toward the goal of isolating the consensus code completely. As
soon as it exists in a repository by itself, it is easier to enforce a
different regime of change control there, or even freeze it completely
over time. To keep track of consensus changes one'd only have to
follow that repository, instead of filter it between tons of GUI, RPC
or utility commits.
IMO having the consensus isolated into a portable self-contained
library is the most important goal of Bitcoin Core project at this
point. I've tried to keep the amount of unnecessary refactoring down,
but some is unfortunately unavoidable.
I'm sure we can find a way to rebase CHECKLOCKTIMEVERIFY so that it
can land in 0.11.
Wladimir
|
