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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z5aCs-00057R-Hx
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 13:50:14 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.52 as permitted sender)
client-ip=209.85.215.52; envelope-from=pieter.wuille@gmail.com;
helo=mail-la0-f52.google.com;
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5aCr-0005cy-HA
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 13:50:14 +0000
Received: by lacny3 with SMTP id ny3so54787414lac.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 06:50:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.45.98 with SMTP id l2mr13151933lam.77.1434635407138;
Thu, 18 Jun 2015 06:50:07 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Thu, 18 Jun 2015 06:50:07 -0700 (PDT)
In-Reply-To: <CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
Date: Thu, 18 Jun 2015 15:50:07 +0200
Message-ID: <CAPg+sBg4Du++h4p2jf4Trrx5OW8v13VEdmiwtWn71bynOs+UFw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c1b572d3257e0518cb15d8
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5aCr-0005cy-HA
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 13:50:14 -0000
--001a11c1b572d3257e0518cb15d8
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <mike@plan99.net> wrote:
> OK, let's agree to unpack the two things.
>
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>
> But let's leave it to one side for a moment.
>
> Let's focus on the other issue: what happens if the Bitcoin Core
> decision making process goes wrong?
>
Why do you keep talking about Bitcoin Core maintainers? The means for doing
a hard fork is convincing the network to run modified code, whether that is
a new version of Bitcoin Core or a fork of it, or something else entirely.
If I see consensus about a proposed network change, I will be in favor of
implementing it in Bitcoin Core. But we're not at that point. There is no
network change proposed with consensus. There is not even a patch to be
discussed. There are working proposals, and people are talking about them.
This is good.
I think maintainers of particular software should not be, and are not those
who decide the network's rules. People running the code are. Of course
maintainers have a large influence, but so do other people - like you.
> This was a reference to a post by Gregory on Reddit where he said if
Gavin were to do a pull request for the block size change and then merge
it, he would revert it. And I fully believe he would do so!
I believe so too, and I would do the same. Because I believe implementing a
consensus rule change without having very good expectations that the
network will adopt it, is reckless from the point of view of maintainers,
for all reasons I have mentioned before.
--
Pieter
--001a11c1b572d3257e0518cb15d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <span dir=3D"l=
tr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.ne=
t</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>OK, let's agre=
e to unpack the two things.</div><div><br></div><div>The first issue is how=
are decisions made in Bitcoin Core? I struggle to explain this to others b=
ecause I don't understand it myself. Is it a vote of people with commit=
access? Is it a 100% agreement of "core developers" and if so, w=
ho are these people? Is it "whoever reverts the change last"?=C2=
=A0 Could I write down in a document a precise description of how decisions=
are made? No, and that's been a fairly frustrating problem for a long =
time.</div><div><br></div><div>But let's leave it to one side for a mom=
ent.</div><div><br></div><div>Let's focus on the other issue: =C2=A0 wh=
at happens if the Bitcoin Core decision making process goes wrong?=C2=A0</d=
iv></div></div></div></blockquote><div><br></div><div>Why do you keep talki=
ng about Bitcoin Core maintainers? The means for doing a hard fork is convi=
ncing the network to run modified code, whether that is a new version of Bi=
tcoin Core or a fork of it, or something else entirely.<br><br></div><div>I=
f I see consensus about a proposed network change, I will be in favor of im=
plementing it in Bitcoin Core. But we're not at that point. There is no=
network change proposed with consensus. There is not even a patch to be di=
scussed. There are working proposals, and people are talking about them. Th=
is is good.<br><br></div><div>I think maintainers of particular software sh=
ould not be, and are not those who decide the network's rules. People r=
unning the code are. Of course maintainers have a large influence, but so d=
o other people - like you.<br><br></div><div>> This was a reference to a=
post by Gregory on Reddit where he said if=20
Gavin were to do a pull request for the block size change and then merge
it, he would revert it. And I fully believe he would do so!<br><br></div><=
div>I believe so too, and I would do the same. Because I believe implementi=
ng a consensus rule change without having very good expectations that the n=
etwork will adopt it, is reckless from the point of view of maintainers, fo=
r all reasons I have mentioned before.<br><br></div>-- <br><div>Pieter<br><=
br></div></div></div></div>
--001a11c1b572d3257e0518cb15d8--
|
