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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <cory@atlastechnologiesinc.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F0287489
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 23:42:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
[209.85.212.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4264D213
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 23:42:12 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so1022370wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 16:42:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=WPFsGm+G+svGAuJuljwgSJN6uvhTxP6KREEJTXSABJs=;
b=CLd8oJgB/qhDplH1wGfz2RMuwo4hiwbGKNWX37TS3Qfdj94KKvxDR+nyNWKrDkQ3KU
jz3AKhRNFirzHJb6iwPch9RftbppebIJ2j44yiqukdJDHmGdqIGcod+ifM+hCUOEOvHf
X2BX2vDr56I5ost/EZSRPjFSdDrihYYitVXCKdYPhSsvFJ50fKYYNyk+lA0xpqU4Flj2
UYUQHd1qXdLr7F+mFak4m6XoVbbEEb1s18/ElKRjB+sDyabDLLCbsjVe1WtmIvg/vLaT
BbOlPgrUr7Y/XJo3I9newbLUvQyEHw2Jj80W/RrMg6/ZPuvgAS7iTNfRaZQQ9ugpLTLI
gGcw==
X-Gm-Message-State: ALoCoQkbbsAH9f/FmMihliyeLpfLEp/G099NDfVD2EiuxTtr7UpXEuDveTO9XUEzI9NvqPpY5sQB
MIME-Version: 1.0
X-Received: by 10.194.63.42 with SMTP id d10mr10706956wjs.92.1437608530905;
Wed, 22 Jul 2015 16:42:10 -0700 (PDT)
Received: by 10.194.168.167 with HTTP; Wed, 22 Jul 2015 16:42:10 -0700 (PDT)
In-Reply-To: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
Date: Wed, 22 Jul 2015 19:42:10 -0400
Message-ID: <CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
From: Cory Fields <lists@coryfields.com>
To: Raystonn <raystonn@hotmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 22 Jul 2015 23:42:13 -0000
I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what their consensus
parameters should be at runtime. In fact, that's already in use:
./bitcoind -testnet. As mentioned in another thread, the chain params
could even come from a config file that the user could edit without
touching the code.
I realize that it'd be opening Pandora's Box, and likely met with very
loud and reasonable arguments about the obvious terrible implications,
but it's at least an alternative to the current status quo of Core's
conflation with the consensus rules. The idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.
With that in place, consensus changes would be more about lobbying and
coalitions, and less about pull requests.
Cory
On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference. If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I wouldn't go quite that far. The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>
> The developers propose a new version, by publishing a new release. The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work. Consensus is most
> strongly measured by user actions after software release. If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
