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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean
 CHECKLOCKTIMEVERIFY can't be merged
Precedence: list

> 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