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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 90E9F8B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Jul 2015 22:34:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 886651BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Jul 2015 22:34:03 +0000 (UTC)
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 0FB81417BF;
Wed, 1 Jul 2015 22:34:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1435790043; bh=TEHCfneF9rzs8aBbtzaPNAbcaaA83ymR115kQ5TcNss=;
h=Date:From:To:Subject:References:In-Reply-To:From;
b=UW76gc5ZfDTXEN9IVMr4LaBDEx2jnQ1aDZQ/IB4XSidG228Q9A3pO29FgsGvA5+52
mH8DIye4GePGiPUEvd+AAEqVHclfWB9GRHOsoBNvS+0sN/6/RTjLtvijtHA7Qvj9rD
G9k4o2+8qm5YkzzptjpVypEEYNorq0VnKHllpdnk=
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id 9FC572253B
Message-ID: <55946AD9.3070300@riseup.net>
Date: Wed, 01 Jul 2015 15:34:01 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Milly Bitcoin <milly@bitcoins.info>, bitcoin-dev@lists.linuxfoundation.org
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl> <558B4632.8080504@bitcoins.info> <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com> <CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com>
<558C9FE3.6000804@bitcoins.info>
In-Reply-To: <558C9FE3.6000804@bitcoins.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
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, 01 Jul 2015 22:34:04 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Possibly relevant to this discussion (though old)
https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
think?)
and
https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
(which cites gavin's gist shown above)
On 06/25/2015 05:42 PM, Milly Bitcoin wrote:
> That description makes sense. It also makes sense to separate out
> the hard fork from the soft fork process. Right now some people
> want to use the soft fork procedure for a hard fork simply because
> there is no other way to do it.
>
> I am under the impression that most users expect
> changes/improvements that would require a hard fork so I think some
> kind of process needs to be developed. Taking the responsibility
> off the shoulder of the core maintainer also makes sense. The hard
> fork issue is too much of a distraction for people trying to
> maintain the nuts and bolts of the underlying system.
>
> I saw a suggestion that regularly scheduled hard forks should be
> planned. That seems to make sense so you would have some sort of
> schedule where you would have cut off dates for hard-fork BIP
> submissions. That way you avoid the debates over whether there
> should be hard forks to what should be contained within the hard
> fork (if needed). It makes sense to follow the BIP process as
> close as possible. Possibly adding another step after "Dev
> acceptance" to include input from others such as
> merchants/exchanges/miners/users. It will only be an approximation
> of "decentralization" and the process won't be perfect but if you
> want to move forward then you need some way to do it.
>
> Russ
>
>
> On 6/25/2015 4:05 PM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
>> <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
>>
>> I'm sorry but this is absolutely not the case, Milly. The reason
>> that people get defensive is that we have a carefully
>> constructed process that does work (thank you very much!) and is
>> well documented.
>>
>>
>> There is no process for handling hard forks, which aren't bug
>> fixes.
>>
>> Soft forks have a defined process of something like
>>
>> - BIP proposal + discussion - Proposed code - Dev acceptance -
>> Release - Miner vote/acceptance
>>
>> The devs have a weak veto. If they refuse to move forward with
>> changes, miners could perform a soft fork on their own. They
>> don't want to do that, as it would be controversial and the devs
>> know the software better.
>>
>> The miner veto is stronger (for soft forks) but not absolute.
>> The devs could checkpoint/blacklist a chain if miners implemented
>> a fork that wasn't acceptable (assuming the community backed
>> them).
>>
>> When ASICs arrived, it was pointed out by some that the devs
>> could hit back if ASICs weren't made publicly available. If they
>> slightly tweaked the hashing algorithm, then current generation
>> of ASICs would be useless. The potential threat may have acted
>> as a disincentive for ASIC manufacturers to use the ASICs
>> themselves.
>>
>> Moving forward with agreement between all involved is the
>> recommended and desirable approach.
>>
>> Consensus between all parties is the goal but isn't absolutely
>> required. This escape valve is partly what makes consensus work.
>> If you dig your heels in, then the other side can bypass you, but
>> they have an incentive to try to convince you to compromise
>> first. The outcome is better if a middle ground can be found.
>>
>> Hard forks are different. The "checks and balances" of weak
>> vetoes are not present. This means that things can devolve from
>> consensus to mutual veto. Consensus ceases to be a goal and
>> becomes a requirement.
>>
>> This is partly a reflection of the nature of hard forks.
>> Everyone needs to upgrade. On the other hand, if most of the
>> various groups upgrade, then users of the legacy software would
>> have to upgrade or get left behind. If 5% of the users decided
>> not to upgrade, should they be allowed to demand that nobody else
>> does?
>>
>> There is clearly some kind of threshold that is reasonable.
>>
>> The fundamental problem is that there isn't agreement on what
>> the block size is. Is it equal in status to the 21 million BTC
>> limit?
>>
>> If Satoshi had said that 1MB was part of the definition of
>> Bitcoin, then I think people would accept it to the same extent
>> as they accept the 21 million coin limit. It might cause people
>> to leave the coin though.
>>
>> It was intended to be temporary, but people have realized that
>> it might be a good idea to keep it. In effect both sides could
>> argue that they should be considered the status quo.
>>
>> I wonder if a coin toss would be acceptable :). "Come to an
>> agreement or we decide by coin toss"
>>
>>
>> _______________________________________________ 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
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx
DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob
zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps
v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY
qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj
rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=
=n7Pa
-----END PGP SIGNATURE-----
|
