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 A7E6140A for ; Sat, 8 Apr 2017 04:49:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE43D16A for ; Sat, 8 Apr 2017 04:49:05 +0000 (UTC) Received: by mail-yw0-f177.google.com with SMTP id d191so42350319ywe.2 for ; Fri, 07 Apr 2017 21:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rgrant-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Lskh80Z9fn8USW66K3A4fB/uF+0k9/aHD9Q+GX/twN4=; b=ivg9Cmhd4C32dxRPJzGYs3dhs8x+8W5VtIzaRK9hcVcdePTGwCYmt/N8SYv3JwL258 XKsAu2B4E/X969wnZnUPoY06GB8ktaN/iWWjLM7QFzLFXu9gluEcqsE2sl7QrBJUw94A VqhOhxiJcrk7SCKvmerTsMrCzcdvmDw20NFGayDBt8Ha2iGIO+ysxJAgSw97t86KfnCy h39zsqXdMe1Tczk9T5ZeeV1bS2nx1VlnNtX8jsMzxTen8demi0/QMdDfnA4ned7kdoy7 r6uQd22JrREWZGu6eDAZgd8CEKdUMezLftD7IdHzBp8/Qmf2WZvdGbsB6mdGzyTZyOm7 vcvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Lskh80Z9fn8USW66K3A4fB/uF+0k9/aHD9Q+GX/twN4=; b=FyU1+OdwTDpXBqLKDDdGw9Z2Mxi84sSn4bDVjI/pIbeWbeV+s674fjAoz1gDcyRrH3 yskyhFT+3YQeaNzQtx7ewIFUzGdpumcfNmcs+tT+h7C7y7DxMwMDOgjphqPlPjDMz17T lKfXaKlTUvvX+fGcRsQjOSrTvGxaPxaURETQkstFZgJwyloHp2jeF8P/9cuTA3dxbivI 5jr3XEVFNBJ1bwbrb1pXK9v3Q5buzXfek+0PFlrYdxAZ2hsGnEQMMywcLn6BuGYT+NoP GBfG/loNn8Fi/Rhn720RvkeFVMAGdqZHqyU67ZMPdypOBHeMCu0hlgzSlOqc27x3tg4v 24pw== X-Gm-Message-State: AFeK/H1EIVmJYJfk6ATnhYyf4uPXYs5g1b+bYRK0dBi2Nap6YEBH5yrK4LQHsbbrGhioCryubxOp4oDSIonAvQ== X-Received: by 10.129.98.2 with SMTP id w2mr29085854ywb.336.1491626944925; Fri, 07 Apr 2017 21:49:04 -0700 (PDT) MIME-Version: 1.0 Sender: rgrant@rgrant.org Received: by 10.37.172.210 with HTTP; Fri, 7 Apr 2017 21:48:34 -0700 (PDT) In-Reply-To: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com> References: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com> From: Ryan Grant Date: Fri, 7 Apr 2017 23:48:34 -0500 X-Google-Sender-Auth: baaJbIwIrmS2Je4d0vX81C8cNVc Message-ID: To: praxeology_guy Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 04:49:06 -0000 Praxeology Guy, On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy wrote: > TLDR Unless I'm missing something, your claim that a > misconfiguration would result in a stop chain is wrong because BIP9 > only works on soft forks. If our rule change timing is different from changes on the chain with most work, then (extending Johnson Lau's terminology a bit) we may experience subjective hardfork-ness; due to miners creating blocks which the economic majority goes on to accept, though they have a less restrictive ruleset than ours. > The user would have to adopt a soft fork at a time where no miner > has also done the same, and where someone creates a contradictory > block (which normally wouldn't happen unless someone was being > malicious). Correct for the segwit soft fork, which is narrowing the definition of a nonstandard transaction. It's safe to say that if a block with a tx violating cleanstack were to occur on a non-segwit chain, that it was for malicious reasons. However, some future forks - that a full node experiences as low subjective hardfork-ness (i.e. soft forks) - might restrict more common things. > Never the less, I kind of like the idea of the user being notified > when a newly activated more stringent soft fork rule caused a block > to be rejected. The first time it happens, a message could come up, > and then for some time after maybe it would be logged somewhere > easily accessible. Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that was aware as well, though clients can make these decisions themselves.