1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
Return-Path: <tmagik@hozed.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CB3CADCE
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <hozer@hozed.org>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170714210759.GP4885@hostname.unassigned>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
> <bitcoin-dev@lists.linuxfoundation.org> 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.
|
