Date: Sat, 10 Oct 2015 17:23:26 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151010072326.GA24099@navy>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
	<20151007150014.GA21849@navy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151007150014.GA21849@navy>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

On Thu, Oct 08, 2015 at 01:00:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> *But* a soft fork that only forbids transactions that would previously
> not have been mined anyway should be the best of both worlds, [...]

>   * more restrictive than consensus, but less restrictive than policy
>     (safe soft fork)

> Hmm, in particular, following this line of thinking it's not clear to
> me that BIP68 is actually less restrictive than current policy?

As was discussed on the weekly meeting [0], turns out it *is* less
restrictive than current policy. IsStandardTx currently returns a failure
if the tx version is greater than 1, and per BIP68, nSequence will only
be inforced with tx version of 2 or greater.

So afaics, BIP 65 (OP_CLTV), BIP 68 (nSequence) and BIP 112 (OP_CSV)
are all "safe soft forks", and if activated won't cause SPV nodes to
see a significant uptick in reorgs, double-spends etc. (They'll still
be vulnerable to people deliberately spending hashpower to mine invalid
blocks, but that's a problem at any point, independent of whether a
soft-fork is underway)

[0] http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.log.html#l-312

Cheers,
aj