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 C2DF1F1E for ; Mon, 8 Feb 2016 02:44:42 +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 313FF15E for ; Mon, 8 Feb 2016 02:44:42 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1aSboa-0002HB-FD; Mon, 08 Feb 2016 12:44:38 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 08 Feb 2016 12:44:32 +1000 Date: Mon, 8 Feb 2016 12:44:32 +1000 From: Anthony Towns To: Gavin Message-ID: <20160208024432.GA21065@sapphire.erisian.com.au> References: <232901d161dd$a35f8d30$ea1ea790$@xbt.hk> 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=-2.1 required=5.0 tests=BAYES_00,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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Hardfork bit BIP 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: Mon, 08 Feb 2016 02:44:42 -0000 On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote: > > On Feb 7, 2016, at 2:27 PM, wrote: > > Normal version number only suggests softforks, which is usually not a concern for SPV clients. > Soft forks affect the security of low-confirmation (zero or one) transactions sent to SPV wallets even more than hard forks, This isn't true for soft-forks that only forbid transactions that would already be rejected for forwarding and mining due to being non-standard. > and because many users and businesses choose convenience over airtight security I would argue transaction validation rule changes are a VERY big concern for lightweight clients. I agree on that point; but ensuring soft-forks only affect non-standard transactions already addresses that concern in every way I've been able to discover. Cheers, aj