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
|
Return-Path: <s7r@sky-ip.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7532D83D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 13:37:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outbound.mailhostbox.com (outbound.mailhostbox.com
[162.222.225.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 75F41124
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 13:36:58 +0000 (UTC)
Received: from [0.0.0.0] (exit1.torproxy.org [89.187.142.208])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id F3B8A360F34;
Thu, 25 Jun 2015 13:36:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
s=20110108; t=1435239416;
bh=e/s5vQsBzdQu/bdWWU092FKcvRXSMkN1jUeGFCCnMUw=;
h=Date:From:Reply-To:To:Subject:References:In-Reply-To;
b=HfMd+iyr4jBHS/tiAvtgJZHzu7Y3qJOxT9L0ykiNCWJoaUQ5/SXYPQHD54NbwebFX
9K6eNE85QY+gjlRE8HpFiftuTM/UQJFnt7/PMDckU5rOeKsNZVdvSBfw/iXG5jDrwG
2LRkBIoKVn6EF3489fjKPgFvYJ3kBADho53bpqm8=
Message-ID: <558C03F1.70603@sky-ip.org>
Date: Thu, 25 Jun 2015 16:36:49 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
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>
In-Reply-To: <558B4632.8080504@bitcoins.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=Rpo4V3SK c=1 sm=1 tr=0
a=V+Otk98JblcXrRsdFwbjdA==:117 a=V+Otk98JblcXrRsdFwbjdA==:17
a=Tqh50d3mAAAA:8 a=-NIMs_s3AAAA:8 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10
a=bvjBBkZ6AAAA:8 a=NEAV23lmAAAA:8 a=ag1SF4gXAAAA:8
a=oDWC3AKl53ix006OzewA:9
a=eO1_j4N6rBA6C41q:21 a=YBuusii7EQL4AEcS:21 a=pILNOxqGKmIA:10
a=vlnTKxGs3H4A:10
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,URIBL_BLACK 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] BIP Process and Votes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: s7r@sky-ip.org
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: Thu, 25 Jun 2015 13:37:05 -0000
I guess you mean Wladimir here. You are wrong, Wladimir does decide and
if you look at the commit history on github.com for bitcoin core you
will see, that he does actually decide and does it really good.
He just does not want to decide (and he really should not) on CONSENSUS
changes or protocol changes. This is totally different.
Stop the analogy with "other open source projects". This is an open
source project (the code part) but unlike any other open source projects
which can just be forked, without affecting the other users, in bitcoin
we need all the users to trust a single blockchain, so it'll have value.
If some users fork the blockchain and change consensus rules, they are
not just harming themselves, they are affecting ALL the users, since
such a thing would have strong impact over the BTC/FIAT rate, affecting
everyone in the ecosystem. There is economics involved here and human
element, things which are hard to fix via code, even if the code is
developed in open source style.
It's one thing to decide to merge some patches, improve the code, etc.
and another thing to decide for consensus rules when you literary play
with 4 billion united states dollars of other people's money. This
shouldn't be Wladimir's responsibility, it's just unfair for people to
throw this on his shoulders.
I do not under any circumstances suggest that the consensus should
remain as it is now forever. We need to improve it, but this should not
be on the maintainer. I've seen smart suggestions on this mail list
where consensus changes can be made during a long period of time,
through soft forks, where all users/miners/exchangers/merchants get the
chance to choose / take action.
On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
> I have seen this question asked many times. Most developers become
> defensive and they usually give a very vague 1-sentence answer when this
> question is asked. It seems to be it is based on personalities rather
> than any kind of definable process. To have that discussion the
> personalities must be separated out and answers like "such-and-such
> wouldn't do that" don't really do much to advance the discussion. Also,
> the incentive for new developers to come in is that they will be paid by
> companies who want to influence the code and this should be considered
> (some developers take this statement as an insult when it is just a
> statement of the incentive process).
>
> The other problem you are having is the lead developer does not want to
> be a "decider" when, in fact, he is a very significant decider. While
> the users have the ultimate choice in a practical sense the chief
> developer is the "decider." Now people don't want to get him upset so
> nobody wants to push the issue or fully define the process. Now you are
> left with a broken, unwritten/unspoken process. While this type of
> thing may work with a small group of developers businesses/investors
> looking in from the outside will see this as a risk.
>
> Until you get passed all the personality-based arguments you are going
> to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>> I would like to start a civil discussion on an undefined, or at least
>> unwritten, portion of the BIP process. Who should get to vote on
>> approval to commit a BIP implementation into Bitcoin Core? Is a
>> simple majority of these voters sufficient for approval? If not, then
>> what is?
>>
>> Raystonn
>> _______________________________________________
>> 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
|
