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
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 297C8B73
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Feb 2017 16:50:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DA2818B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Feb 2017 16:50:10 +0000 (UTC)
Received: by mail-pg0-f52.google.com with SMTP id p5so22956895pga.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Feb 2017 08:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=yYkrwUlirpC+lQJyHeWHuBT7/QbUnJAA4QUwqcSFfDI=;
b=ib7uTnz+fIl6/ZLpWqkp/ht62zuqG2MUCYVxxEezdPZSucx6KDwZjGkHX4IKUpSV61
0fuCZCpdmfEFbR52eVlN/OvodLeAA3BUtbEVbuycFuTPRnI9aaGkw13DPNKDxRVoSnnk
P7kPDQ9hmqvd3UtnLqSt3T5iqEv5/yxZWd5Qfh6EkfZL9CSWnZsYF5ulDA8ChBDTz5DC
mzrxg+OOAPbqcfCYImJdvAxklgDVyO3zICGqpDgyE9yvWGL2z2+Eh0uWXrBJaQiViAqv
HSKDujuq/8nr8SDR0s+wRbZcuLhdeZMN0g45SyPvewTesZ+G4t5W4zeLpSW9nzV/Lh0Y
gujw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=yYkrwUlirpC+lQJyHeWHuBT7/QbUnJAA4QUwqcSFfDI=;
b=o6ju4QdFzeqOn5f/HXVN6Wo2gv0NYefHcgAsWaW8XaqwfE7i5kUszY0vagjufsBD10
AdqsTZXTvbf+z7kTkl4f3CwEdlgKH8JP3gf15GeWGPoYKpTr7Sr28oLUqcMcDvZzubrn
aXoJJf2j3NEDj9bcOdh4jICui4rR2F12s0Lx9eX91jXVdqaR0gVnEWTd+xiZYzhslUt1
3++UlwkMV5xAX/FOm2wpUFgVXE1P1KYekPKRAIOS3q5ZAARC+KGRDrAlwScxfXJODf4T
pRIfNSpQE/xTy4Ymh+t8xp8at75bAT5UIUSE37kawn+bm4fMOC8jVYmPVb8EcSGBuYGX
OV6A==
X-Gm-Message-State: AMke39kaJughXcTVtW6YQZ1Xb5OKUh5VlWfyaWz8QLD/V3jKc2ppRK77g3obJ8PnLFumLA==
X-Received: by 10.98.63.24 with SMTP id m24mr21821797pfa.143.1488214209991;
Mon, 27 Feb 2017 08:50:09 -0800 (PST)
Received: from [10.200.137.56] (mobile-166-176-187-41.mycingular.net.
[166.176.187.41]) by smtp.gmail.com with ESMTPSA id
9sm31652846pfk.121.2017.02.27.08.50.08
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 27 Feb 2017 08:50:09 -0800 (PST)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <EMmw5p_aZLoAKdZKan47iSwAq_X9flneBX-1nOOpIpk08NzihG0yZedl0R5G2HLwlrjUCqscSa9uVTKPc83ewQIXbjKOHXSDeX-i8AV7Suw=@protonmail.ch>
Date: Mon, 27 Feb 2017 08:50:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <09746CD6-10FB-4F3B-B4E1-AE12E504141B@voskuil.org>
References: <jo5-7HCZX7tgdMpIQgK85HCPP14FWxvOIbjV_oerIfc-HOP1GbK3SxFX82Ls23yU1L7y95QsFFggddMNdo5Sxy7YhTJhRFN1f8d6PaA8b7s=@protonmail.ch>
<CADL_X_fUuTexNYBt=rZUXRuXpKrpyTiiXYkxTxquispLGV6ezQ@mail.gmail.com>
<EMmw5p_aZLoAKdZKan47iSwAq_X9flneBX-1nOOpIpk08NzihG0yZedl0R5G2HLwlrjUCqscSa9uVTKPc83ewQIXbjKOHXSDeX-i8AV7Suw=@protonmail.ch>
To: shaolinfry <shaolinfry@protonmail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
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: Mon, 27 Feb 2017 16:50:11 -0000
On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>> 3) In terms of complexity for mining pool operators, how well does this m=
odel scale if there are N soft forks and the pool doesn't want to opt-in to a=
ny of them? Couldn't this result in those pool operators having to run not j=
ust one border node, but a multitude of "chained" border nodes if the soft f=
orks are spread across different software implementations?
>=20
> While BIP9 allows for 29 parallel deployments I think it is unrealistic to=
expect there would be such a high number of active parallel deployments at a=
ny one time: History shows soft forks take a minimum of 6 months design, con=
sensus building, coding and testing before deployment. With such a high bar,=
I do not envisage more than a couple of parallel deployments at any given t=
ime. I also do not envisage "conflicting" soft forks, as that would not meet=
consensus from the technical community on the basis of safety and sanity. I=
n any case, the deployment strategy of each soft fork should be considered o=
n a case by case basis.
The relationship between a codebase and chain fork implementations is simila=
r to vendor lock-in, and is being used in a similar manner.
There is nothing preventing a single codebase from implementing all forks an=
d exposing the option to apply any non-conflicting combination of them.
While this has not been the norm libbitcoin now utilizes this approach. Curr=
ently the options to apply any activated Bitcoin forks are exposed via confi=
g. I personally am not working to implement non-activated forks at this poin=
t, but that's just prioritization.
Recently I objected to BIP90. This hard fork is presented as a code simplifi=
cation and a performance optimization. I showed in the discussion that it wa=
s neither. Nevertheless we implemented this additional code and give the use=
r the option to apply it or not. It's application produces no performance be=
nefit, but it ensures that the choice of forks remains in the hands of the u=
ser.
e=
|
