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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1Z5fQI-0005if-Kb
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 19:24:26 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me
designates 192.241.179.72 as permitted sender)
client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
helo=mail.bluematt.me;
Received: from mail.bluematt.me ([192.241.179.72])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z5fQH-0007pf-ES
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 19:24:26 +0000
Received: from [IPv6:2607:fb90:406:1c88:517:fde8:e69b:258b]
(mde0536d0.tmodns.net [208.54.5.222])
by mail.bluematt.me (Postfix) with ESMTPSA id 282AC5563F;
Thu, 18 Jun 2015 19:24:18 +0000 (UTC)
User-Agent: K-9 Mail for Android
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>
MIME-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
From: Matt Corallo <bitcoin-list@bluematt.me>
Date: Thu, 18 Jun 2015 12:24:14 -0700
To: Gavin Andresen <gavinandresen@gmail.com>,Alex Morcos <morcos@gmail.com>
Message-ID: <9BD8D5D8-3A4B-4361-BF4C-25E1019CA428@bluematt.me>
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Z5fQH-0007pf-ES
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.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 19:24:26 -0000
>For example, I think some of the resistance for bigger blocks is coming
>from contributors who are worried they, personally, won't be able to
>keep
>up with a bigger blockchain. They might not be able to run full nodes
>from
>their home network connections (or might not be able to run a full node
>AND
>stream Game of Thrones), on their old raspberry pi machines.
Ive been trying to stay out of these increasingly useless shit-throwing c=
ontests, but I wanted to take objection to this... I highly, highly doubt=
any seriously technical person is making any kind of decision on block s=
ize issues based on their own personal network. If you're assuming this i=
s a serious motivating factor for anyone, then I'm not sure you've even b=
een reading your email or listening to the conversations you've had with =
people over the last year or more.
On June 18, 2015 11:23:33 AM PDT, 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:=20
>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.
>
>
>> It's up to each individual user as to what code they run and what
>rules
>> they enforce. So then why is everyone so up in arms about what Mike
>and
>> Gavin are proposing if everyone is free to decide for themselves? I
>> believe that each individual user should adhere to the principle that
>there
>> should be no changes to the consensus rules unless there is near
>complete
>> agreement among the entire community, users, developers, businesses
>miners
>> etc. It is not necessary to define complete agreement exactly because
>every
>> individual person decides for themselves. I believe that this is
>what
>> gives Bitcoin, or really any money, its value and what makes it work,
>that
>> we all agree on exactly what it is. So I believe that it is
>misleading and
>> bad for Bitcoin to tell users and business that you can just choose
>without
>> concern for everyone else which code you'll run and we'll see which
>one
>> wins out. No. You should run the old consensus rules (on any
>codebase you
>> want) until you believe that pretty much everyone has consented to a
>change
>> in the rules. It is your choice, but I think a lot of people that
>have
>> spent time thinking about the philosophy of consensus systems believe
>that
>> when the users of the system have this principle in mind, it's what
>will
>> make the system work best.
>>
>
>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."
>
>For example, I think some of the resistance for bigger blocks is coming
>from contributors who are worried they, personally, won't be able to
>keep
>up with a bigger blockchain. They might not be able to run full nodes
>from
>their home network connections (or might not be able to run a full node
>AND
>stream Game of Thrones), on their old raspberry pi machines.
>
>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.
>
>
>
>> 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."
|
