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 A916418AD for ; Wed, 30 Sep 2015 23:25:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0892C1ED for ; Wed, 30 Sep 2015 23:25:04 +0000 (UTC) Received: by igbni9 with SMTP id ni9so2873680igb.0 for ; Wed, 30 Sep 2015 16:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0BHU59/x2iDS5JKRWzWdyo+58t4SmJ5kzGeSdp80Pkk=; b=ghrK2cbjkK1l38bLSLsdBWRbL2uxdzoZJe8WRZckfs84Ro9OfoCC/HXqgA/e0Re7lp jCh1KtIf/q3R0hAyKjHTvVFlo372dvqJjVU2U6h1/VmjGUCttMN9eHPGIfcEGVZjOgLd 4y1TFq13zUi0vm9vCUsHDSitJReboDSF8Io53Awfd7DHOq5BFRfXn5kYX+vBFEN2qS8L PwSXIoIRosEsqee+9PJ4TpdSOgyZaWKHKO/GBnUSBYQhGEUeLWJ1BuOVrLQv+Iuj2yZL lYIPWUWD5MZksYi0cWh0duKLhZ08bHVVcraKYneggw1Zhb3LkJxCMQlNyb8usXPOXwYn b02w== MIME-Version: 1.0 X-Received: by 10.50.23.80 with SMTP id k16mr35784igf.62.1443655503525; Wed, 30 Sep 2015 16:25:03 -0700 (PDT) Received: by 10.107.19.30 with HTTP; Wed, 30 Sep 2015 16:25:03 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Wed, 30 Sep 2015 23:25:03 +0000 Message-ID: From: Gregory Maxwell To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev 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: Wed, 30 Sep 2015 23:25:04 -0000 On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik wrote: > It is correct that security is slightly reduced for full nodes that have not > upgraded. It is not correct that the choice is binary, full node or SPV. > > Any user running a not-upgraded full node still retains protection against > many attacks outside the subset related to the feature being introduced. An extra way to look at this is that even absent any rule changes-- users who are asleep at the switch may lose effective security over time because attackers learn new tricks against existing vulnerabilities. Security requires a bit of vigilance, inherently. In many specific cases I think it's hard-to-impossible to articulate a concrete way that security is lost by users at all, excluding some small amplification of orphan blocks. On Wed, Sep 30, 2015 at 9:06 PM, Mike Hearn via bitcoin-dev wrote: > and is trying to mine it, will keep producing invalid blocks forever until > the owner shuts it down and upgrades. This is the outcome guaranteed for absentee miners with a hard fork, but it is not guaranteed for a soft fork. > For instance, any miner that has modified/bypassed IsStandard() can do this, Miners who have changed their code in inadvisable ways can produce invalid blocks as a result. There are many seemingly innocuous ways one can produce invalid blocks, and miners have stumbled on a few of them over the years. Pedantically, modifying IsStandard() will not have this effect: Unknown NOPs are now handled via a script validation flag-- SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS. Experience (e.g. with STRICTDER) has show that script validation flags are much more robust to casual twiddling than IsStandard is. The only way that script validation flags have been observed getting bypassed in the field was a miner that had disabled all signature validation completely (and whom had a not-completely-negligible amount of hashpower. :( )... as it's a lot more clear that you might be exposing yourself to trouble if you mess with the validation flags. > runs an old node from before OP_NOPs were made non-standard. IIRC; There is no released version of Bitcoin that has IsStandard which has failed failed to treat the NOPs as non-standard. There was a brief time in git master between when IsStandardness was relaxed and NOPs were addressed via a validation flag but I am reasonably confident that didn't make it into a release. Regardless, anyone actually running that code of that vintage would already be incompatible with the current network already due to prior soft forks. And as a matter of fact, invalid CLTVs don't currently appear to get mined. Checking this again pre-release would be a good checklist item. For prior soft-forks we've monitored and tested for this (with the goal of going and yelling at any broken miners to fix their behavior).