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
|
Return-Path: <dan@osc.co.cr>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 43526A73
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 06:26:28 +0000 (UTC)
X-Greylist: delayed 00:08:53 by SQLgrey-1.7.6
Received: from mail.osc.co.cr (unknown [168.235.79.83])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF893A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Jul 2017 06:26:27 +0000 (UTC)
Received: from [192.168.2.3] (miner1 [71.94.45.245])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested) (Authenticated sender: danda)
by mail.osc.co.cr (Postfix) with ESMTPSA id 254591F2D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 23:17:33 -0700 (PDT)
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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>
From: Dan Libby <dan@osc.co.cr>
Message-ID: <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
Date: Tue, 11 Jul 2017 23:17:24 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 13 Jul 2017 00:54:33 +0000
Subject: [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>
X-List-Received-Date: Wed, 12 Jul 2017 06:26:28 -0000
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.
At this time, I would like to have some of the more recent features, but
without the possibility that my node will activate segwit, until I
choose to.
As I understand it, there is not any user setting that can disable
segwit from activating on my node. If there was, I would use it.
Please correct me if wrong.
I am here to ask what is the simplest code change (fewest LOC changed) I
can make to 0.14.2+ code that would disable segwit from activating and
keep my node acting just like a legacy node with regards to consensus
rules, even if/when the rest of the network activates segwit.
I think, more generally, the same question applies to most any Bip9
versionbits feature.
I'm not looking for reasons NOT to do it, only HOW to do it without
unwanted side-effects. My first untested idea is just to change the
segwit nTimeout in chainparams.cpp to a date in the past. But I figured
I should ask the experts first. :-)
thanks.
ps: full disclosure: I may be the only one who wants this, but if
successful, I do plan to release my changes in case someone else wishes
to run with status-quo consensus rules.
|
