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 7CFA815CC for ; Tue, 6 Oct 2015 06:20:37 +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 10695A9 for ; Tue, 6 Oct 2015 06:20:37 +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 1ZjLc2-0007lc-7P for ; Tue, 06 Oct 2015 16:20:35 +1000 Received: by navy.erisian.com.au (sSMTP sendmail emulation); Tue, 06 Oct 2015 16:20:31 +1000 Date: Tue, 6 Oct 2015 16:20:31 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151006062030.GB1054@navy> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 06 Oct 2015 06:20:37 -0000 On Mon, Oct 05, 2015 at 06:46:28PM +0200, Mike Hearn via bitcoin-dev wrote: > The example is this: find someone that accepts 1-block confirmed > transactions in return for something valuable. There are plenty of them out > there. Once the soft fork starts, send a P2SH transaction that defines a > new output controlled by OP_CLTV. It will be incorporated into the UTXO set > by all miners because it's opaque (p2sh). > > Now send a transaction that pays the merchant, and make it spend your > OP_CLTV output with an invalid script. New nodes will reject it as a rule > violator. Old nodes won't. Old nodes running bitcoind will see it as OP_NOP2, and will reject it unless they've manually disabled SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS, which (aiui) has been available since bitcoin 0.10 [0], but not backported to 0.8 or 0.9. [0] https://github.com/bitcoin/bitcoin/commit/0391423 That covers about 4700/5880 nodes going by bitnodes.21.co; but I can't tell how many miners it covers. Further, AIUI, nodes running 0.8 or 0.9 will still apply IsStandard() checks to scripts attempting to spend p2sh outputs [1], so will also fail to either mine or relay your OP_NOP2 payment. [1] https://github.com/bitcoin/bitcoin/commit/6259937 > So at some point an old miner will create a > block containing your invalid transaction, the merchant will think they got > paid, they'll give you the stuff and the fraud is done. My understanding is that this isn't supposed to be a problem because you won't be able to find an old miner that will do that; released versions of bitcoin already block it by default. Sure, someone could disable those checks and not pay attention to a soft fork that will cause their blocks to be orphaned, but I'm not seeing why that's any different a threat compared to someone deliberately mining invalid blocks to do 1-confirmation doublespends against merchants not running a full node. At least, that's my understanding, and I'm not an expert, so corrections appreciated. Cheers, aj