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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Z5esg-0002Ik-TZ
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:49:42 +0000
Received: from mail-wg0-f54.google.com ([74.125.82.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5esf-0006jR-FJ
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:49:42 +0000
Received: by wgzl5 with SMTP id l5so71397314wgz.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 11:49:35 -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=DMQxOVV20TKbbTcAP0WhbvGyYG4N63NTN8jtI7fzpzg=;
b=bEBfmDzR2c4UWxOVvnb0AP9UZdicFdDep7pXuK9naN6fq/0TeqVxfb8DQ3F7cT/fh3
X/flYgijvfsfp6VE7ybk+9eA4d1iUoHGyS9aGxLlS2uV0SVSG4FSzhkvVaNHAycxgrME
X09BPIFxn0uStUEc8QHXqNN95XXLacjW6t526cDP7JcVCy7CForI3N9Nay9huQbZjlpI
oN+MHiFarOOeYP0RAnbgKo3odR4wKibGtpbPk+w9YlCHDbpRAxsm03otcyNqjKwOjCOr
H/XeoCoCgN93tOiR9RxtN4Iz9l7ObVrZLNVEEULtbWzCxGsGIgYzLzNsVcTC6FyMDx2b
NExA==
X-Gm-Message-State: ALoCoQnCSAc4HR3v42L1LLPtHfSvlvWuZdaNafDu7hbzkge5EaRQyo78BI3t2JGIi/XuptDParA/
MIME-Version: 1.0
X-Received: by 10.194.58.7 with SMTP id m7mr16938362wjq.109.1434653375393;
Thu, 18 Jun 2015 11:49:35 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Thu, 18 Jun 2015 11:49:35 -0700 (PDT)
In-Reply-To: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
<CAJHLa0OKXaUD6MnN4N6RGbNwrXx43jBm9MiELQK6BRw1OL3HNA@mail.gmail.com>
<0ede5c200ce70e4d92541dd91749b4ea@riseup.net>
<CAJHLa0NiDamkrbW2TMoTLqMPhzw0LBboNp1+_atBGDYMa135uw@mail.gmail.com>
<e6da277c39b0354cdf24361e20a1fce2@riseup.net>
<CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>
<CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
Date: Thu, 18 Jun 2015 20:49:35 +0200
Message-ID: <CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5esf-0006jR-FJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 18:49:42 -0000
On Thu, Jun 18, 2015 at 8:23 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos@gmail.com> wrote:
>>
>> Let me take a pass at explaining how I see this.
>>
>> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
>> the decider but he works under a process that is well understood by
>> developers on the project in which he takes under reasonable consideration
>> other technical opinions and prefers to have clear agreement among them.
>
>
> Yes.
>
>> 2) Changes to the consensus rules: As others have said, this isn't
>> anyone's decision for anyone else.
>
>
> Yes.
>
> [...]
>
> I don't think I agree with "pretty much everybody", because status-quo bias
> is a very powerful thing. Any change that disrupts the way they've been
> doing things will generate significant resistance -- there will be 10 or 20%
> of any population that will take a position of "too busy to think about
> this, everything seems to be working great, I don't like change, NO to any
> change."
But according to Alex's explanation (which I think is very good
leaving asides some cases like change of the pow hashing function, for
example) there's no individual that can force or veto a change. It is
the decision of each individual user and their own "pretty much
everybody" may vary. But this "pretty much everybody" is what Mark
referred to with the "I know it when I see it."
> The criteria for me is "clear super-majority of the people and businesses
> who are using Bitcoin the most," and I think that criteria is met.
If you recommend users to apply changes when this criterion is met but
you know there's still many users who don't agree with the change,
then you're acting irresponsibly by promoting a chaotic consensus fork
where coins can be spent in both chains at once.
Well...unless you're promoting it as an altcoin that simply happens to
distribute part of the initial monetary based to bitcoin holders at
block X and whose genesis block is equal to bitcoin's genesis block at
block X. I guess in that case you wouldn't necessarily be
irresponsible.
"Miner's vote" is irrelevant here since it cannot tell you anything
about users adoption (besides miner's adoption of course).
>> 3) Code changes to Core that do change consensus: I think that Wladimir,
>> all the other committers besides Gavin, and almost all of the other
>> developers on Core would defer to #2 above and wait for its outcome to be
>> clear before considering such a code change.
>
>
> Yes, that's the way it has mostly been working. But even before stepping
> down as Lead I was starting to wonder if there are ANY successful open
> source projects that didn't have either a Benevolent Dictator or some clear
> voting process to resolve disputes that cannot be settled with "rough
> consensus."
But this is only relevant for the point 1. Software projects can have
dictators, forks and everything else other free software projects
have. But consensus-based p2p blockchains cannot change their rules in
the same way, otherwise they're centralized.
THERE CANNOT BE A VOTING PROCESS FOR CONSENSUS CHANGES.
If anybody can vote, hod do you prevent the sibyls from outvoting everyone?
If not everybody can vote, how is the voters' list determined without
centralizing the system?
If we had a technical solution to this problem we wouldn't need proof
of work in the first place!!
|
