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
|
Return-Path: <asperous2@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 77654ED0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Sep 2015 21:37:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DED57124
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Sep 2015 21:37:02 +0000 (UTC)
Received: by igbni9 with SMTP id ni9so23427545igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 04 Sep 2015 14:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:content-type;
bh=Ml0RMFjQZxfcQzQfJu2Y3+qtAQe2b/3U4ibQnfWVrac=;
b=ViGXR9XB74eaonOAgnFH92Dov6VRhl1jtVfWJ6vU0BLNDjw/g6WIV8hhHkWAtOeErE
R/sZfKMt3jFk5eG6XLhBaJ4OFp3OQ6KqFD/ScEFGmgHxkETHgHUiSoyBtt/KPhhDNVsa
HIbRQhqoItTZDiAX+urhBDUqDk3MLGSoZiyDF5zIarkW4xOMCPBvELDbvkpkmvLpHhBN
rlZA/pLPcLGNJBQ8DyKGVYUwbo883vDQ+C35vfFzk4CfUy0uLF8uiyLYPPirYhtUgJ07
cuNAZdb+ldtMWBbsGNJKw+hYmqLydQtUTnObotPXtlegtc+wTwnf3AvPDC4Ow0uGuo4S
of8g==
X-Received: by 10.50.118.33 with SMTP id kj1mr685737igb.97.1441402622382; Fri,
04 Sep 2015 14:37:02 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Fri, 4 Sep 2015 14:36:42 -0700 (PDT)
In-Reply-To: <201509042101.11839.luke@dashjr.org>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
<CADJgMzvanj41Dfa4kQsq5SVvt-Zeee2SOfD3Uws-FpBQsyZsqg@mail.gmail.com>
<CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>
<201509042101.11839.luke@dashjr.org>
From: Andy Chase <theandychase@gmail.com>
Date: Fri, 4 Sep 2015 14:36:42 -0700
X-Google-Sender-Auth: 0To_8VVFQvr0C0XIgFwVeAhV6WM
Message-ID: <CAAxp-m8pgvHqUcmjCt6W5uscgb9ErtiTHdR0-nKU6OVdCE7rXA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org,
pete@petertodd.org
Content-Type: multipart/alternative; boundary=089e012947524918ac051ef2b3ef
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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/Draft] BIP Acceptance Process
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: Fri, 04 Sep 2015 21:37:03 -0000
--089e012947524918ac051ef2b3ef
Content-Type: text/plain; charset=UTF-8
I understand your concerns. What kinds of changes do you think should go
through a process like this? Just hard forks?
I was thinking that an advantage of making all BIPs use this process is
that it makes it familiar and well used. Kinda like a muscle grows stronger
with use. If only hard forks go through the process then there's the risk
that the process has to be spun up whenever they happen which might cause
confusion.
Another reason I was thinking is that even small, local changes, it doesn't
hurt to have a few more people take a look at it and approve it.
The bureaucracy only applies to BIPs, not PRs. There's only been 18
approved/final/accepted BIPs in 4 years since BIP-0001. That's only about
~5 per year. I get that bureaucracy is often a waste of time, but I just
don't think every second counts for these things.
On Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr <luke@dashjr.org> wrote:
> On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> > Who makes high-level Bitcoin decisions? Miners, client devs, merchants,
> or
> > users? Let's set up a system where everyone has a say and clear
> acceptance
> > can be reached.
>
> For hardforks (removing consensus rules), economic consensus: people who
> accept payment in bitcoins weighted by their actual volume of such
> payments.
> A supermajority subset may arguably be sufficient for some hardforks (which
> don't violate Bitcoin's social contract) since they can effectively compel
> the remaining economy to comply.
>
> For softforks (adding consensus rules), a majority of miners: they can "51%
> attack" miners who don't go along with it.
>
> Anything else does not necessarily need universal agreement, so are
> completely up to the whim of individual software projects. If someone
> doesn't
> like a decision in Core (for example), they can safely fork the code. If
> any
> significant amount of people use their fork, then the BIP is accepted
> whether
> or not Core later adopts it.
>
> Note this "system" is really describing a lack of a system - that is, what
> naturally must happen for changes to occur. Softforks have a relatively
> mature technical method for measuring support and deploying (which I
> believe
> someone else is already working on a BIP describing), but the same thing is
> impractical for hardforks. Some formal way to measure actual economic
> acceptance seems like a good idea to study, but it needs to be reasonably
> accurate so as to not change the outcome from its natural/necessary result.
>
> Luke
>
--089e012947524918ac051ef2b3ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I understand your concerns. What kinds of changes do you t=
hink should go through a process like this? Just hard forks?<div><br></div>=
<div>I was thinking that an advantage of making all BIPs use this process i=
s that it makes it familiar and well used. Kinda like a muscle grows strong=
er with use. If only hard forks go through the process then there's the=
risk that the process has to be spun up whenever they happen which might c=
ause confusion.</div><div><br></div><div>Another reason I was thinking is t=
hat even small, local changes, it doesn't hurt to have a few more peopl=
e take a look at it and approve it.</div><div><br></div><div>The bureaucrac=
y only applies to BIPs, not PRs. There's only been 18 approved/final/ac=
cepted BIPs in 4 years since BIP-0001. That's only about ~5 per year. I=
get that bureaucracy is often a waste of time, but I just don't think =
every second counts for these things.</div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr <span=
dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@=
dashjr.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span>On Friday, Septe=
mber 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:<br>
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants=
, or<br>
> users? Let's set up a system where everyone has a say and clear ac=
ceptance<br>
> can be reached.<br>
<br>
</span>For hardforks (removing consensus rules), economic consensus: people=
who<br>
accept payment in bitcoins weighted by their actual volume of such payments=
.<br>
A supermajority subset may arguably be sufficient for some hardforks (which=
<br>
don't violate Bitcoin's social contract) since they can effectively=
compel<br>
the remaining economy to comply.<br>
<br>
For softforks (adding consensus rules), a majority of miners: they can &quo=
t;51%<br>
attack" miners who don't go along with it.<br>
<br>
Anything else does not necessarily need universal agreement, so are<br>
completely up to the whim of individual software projects. If someone doesn=
't<br>
like a decision in Core (for example), they can safely fork the code. If an=
y<br>
significant amount of people use their fork, then the BIP is accepted wheth=
er<br>
or not Core later adopts it.<br>
<br>
Note this "system" is really describing a lack of a system - that=
is, what<br>
naturally must happen for changes to occur. Softforks have a relatively<br>
mature technical method for measuring support and deploying (which I believ=
e<br>
someone else is already working on a BIP describing), but the same thing is=
<br>
impractical for hardforks. Some formal way to measure actual economic<br>
acceptance seems like a good idea to study, but it needs to be reasonably<b=
r>
accurate so as to not change the outcome from its natural/necessary result.=
<br>
<span><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div></div>
--089e012947524918ac051ef2b3ef--
|
