From: Andy Chase <theandychase@gmail•com>
To: Luke Dashjr <luke@dashjr•org>,
bitcoin-dev@lists•linuxfoundation.org, pete@petertodd•org
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
Date: Fri, 4 Sep 2015 14:36:42 -0700 [thread overview]
Message-ID: <CAAxp-m8pgvHqUcmjCt6W5uscgb9ErtiTHdR0-nKU6OVdCE7rXA@mail.gmail.com> (raw)
In-Reply-To: <201509042101.11839.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3158 bytes --]
next prev parent reply other threads:[~2015-09-04 21:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 0:30 Andy Chase
2015-09-04 0:41 ` Luke Dashjr
2015-09-04 0:52 ` Andy Chase
2015-09-04 0:43 ` Bryan Bishop
2015-09-04 4:40 ` Andy Chase
2015-09-04 19:20 ` Btc Drak
2015-09-04 20:13 ` Andy Chase
2015-09-04 20:31 ` Peter Todd
2015-09-04 20:42 ` Martin Becze
2015-09-04 21:05 ` Milly Bitcoin
2015-09-04 21:01 ` Luke Dashjr
2015-09-04 21:36 ` Andy Chase [this message]
2015-09-04 21:45 ` Luke Dashjr
2015-09-05 21:19 ` Andy Chase
[not found] ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
2015-09-06 20:44 ` Andy Chase
2016-01-19 2:12 ` Luke Dashjr
2016-01-19 4:23 ` Andy Chase
2016-01-19 6:07 ` Dave Scotese
2015-09-07 19:37 ` Btc Drak
2015-09-10 1:21 ` Andy Chase
2015-09-12 23:50 ` Andy Chase
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAxp-m8pgvHqUcmjCt6W5uscgb9ErtiTHdR0-nKU6OVdCE7rXA@mail.gmail.com \
--to=theandychase@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox