Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB3CADCE for ; Fri, 14 Jul 2017 21:11:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bc.grid.coop (bc.grid.coop [162.221.205.91]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4C9563CB for ; Fri, 14 Jul 2017 21:11:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) (uid 1000) by bc.grid.coop with local; Fri, 14 Jul 2017 21:07:59 +0000 id 0000000000080087.00000000596932AF.000030D8 From: Troy Benjegerdes To: Gregory Maxwell , Bitcoin Protocol Discussion Message-ID: <20170714210759.GP4885@hostname.unassigned> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com> <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 29 Jul 2017 23:32:19 +0000 Subject: Re: [bitcoin-dev] how to disable segwit in my build? 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: , Date: Fri, 14 Jul 2017 21:11:07 -0000 X-Original-Date: Fri, 14 Jul 2017 21:07:59 +0000 X-List-Received-Date: Fri, 14 Jul 2017 21:11:07 -0000 On Thu, Jul 13, 2017 at 01:04:19AM +0000, Gregory Maxwell via bitcoin-dev wrote: > On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev > wrote: > > Hi! > > > > Up to now, I have purposefully been running bitcoin releases prior to > > 0.13.1 as a way to avoid the (possible) segwit activation, at least > > until such time as I personally am comfortable with it. > > It is not simple to do so correctly, I couldn't tell you off the top > of my head; a number of things must be changed it isn't as simple as > disabling the activiation because of the segwit P2P changes. Nor is > it a supported configuration. Even if it were now, it wouldn't be one > we'd continue to support in the future after segwit is active, as > we're likely to drop deployment/compat code. And this attitude is why bitcoin-core is going to get dropped and, hopefully, instead of just one code to rule them all, we will have good specifications and multiple competing implementations. > Can you explain why you wish to do this? It should have absolutely no > adverse impact on you-- if you don't use segwit, you don't use it-- it > may be the case that there is some confusion about the implications > that I could clear up for you... or suggest alternatives that might > achieve your goals. One of the significant adverse impacts of Segwit is the following: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2861 When viewed on Github, less than one third of the consensus-critical code is visible on-screen. This is a maintenance and readability nightmare, in my opinion. There are many good reasons why giving *users* the ability to firewall off that code, maybe even with #ifdefs, as ugly as they are, would provide some much better confidence that one is indeed, not running segwit. I suspect it would help the community a great deal in comfort level if this code were easier to read and used some type of coding standard in which the default github view on the average browser shows all the code without having a "hidden feature" that requires scrolling that has no obvious UI indication you even need to scroll.