From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 363381B7F for ; Sat, 10 Oct 2015 07:23:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A0D0DF for ; Sat, 10 Oct 2015 07:23:34 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=navy.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1ZkoV8-0005Hk-6v for ; Sat, 10 Oct 2015 17:23:31 +1000 Received: by navy.erisian.com.au (sSMTP sendmail emulation); Sat, 10 Oct 2015 17:23:26 +1000 Date: Sat, 10 Oct 2015 17:23:26 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151010072326.GA24099@navy> References: <20150927185031.GA20599@savin.petertodd.org> <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) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 07:23:35 -0000 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