path: root/17/ea72ff3a8c7db0eb5ed0bf3d3cb0d6e670560a

Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B4BE9F07
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 Sep 2015 19:37:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
	[209.85.212.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF0CF1E1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 Sep 2015 19:37:27 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so92827350wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 07 Sep 2015 12:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=eRWFSxSGN+PYAhQh29mu4cpoZ3q9LTyFUb33nQx2mg4=;
	b=PuwzaOd9QNa/cKIQ+Y/Tjt4IjlIj2hnnWlJC1Bzu3b0odL4CVlotRjHCTIDJUfNL1N
	oO5I70LrDmn7ppB1o32i71ugQdFpfyKlWNumxTIhGrfEJRcaHP/A6/jTGmoWDmpWjQ7T
	YorFMHbRazgDdR/IxT9Nr25iMSiygfX3HFQ6IO6G9xLtank+LHpXdlfGppad6ws1MNSk
	UEBnvj1y47ASLY5VCWSaAdp7Jp9S5INYsBkiyWV1NBxi8Y0kLJMcz4/TOyROWjKzgo4Z
	NMd47w9oNQ4LSi4xt6z3afVtK/AUGDUDacAUtxPU/Fs0C91k0N7cC3c54S6txNiPVLPR
	y7sw==
X-Received: by 10.194.187.79 with SMTP id fq15mr39538216wjc.142.1441654646142; 
	Mon, 07 Sep 2015 12:37:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.16 with HTTP; Mon, 7 Sep 2015 12:37:06 -0700 (PDT)
In-Reply-To: <CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<CABaSBaw7hM2qmuR6Z6USy5=V9NGeCPKmHHuVOH=vexDk7kY8OA@mail.gmail.com>
	<CAAxp-m_vo5vJEemR_hRX3hNcUPveA6EHn-ZFMJo8ke59E6BrKw@mail.gmail.com>
	<CADJgMzvanj41Dfa4kQsq5SVvt-Zeee2SOfD3Uws-FpBQsyZsqg@mail.gmail.com>
	<CAAxp-m_EmMbVBqQK9ijoe+n0dAs726TaBX5m1Wgzsv-m1KHdfQ@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 7 Sep 2015 20:37:06 +0100
Message-ID: <CADJgMzuRy_Fbv2UaJ4EZzh8DHhYYixu=k6_Z=sKtNJ9SsLTdyQ@mail.gmail.com>
To: Andy Chase <theandychase@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
	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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Mon, 07 Sep 2015 19:37:29 -0000

Sorry not to reply earlier. I have a rather long post. I've split it
into two sections, one explaining the background and secondly talking
very specifically about your proposal and possible areas to look at.

I think there's a key misunderstanding about BIPs and "who decides
what in Bitcoin". A BIP usually defines some problem and a solutions
or helps communicate proposals to the technical community. They are
sort of mini white papers on specific topics often with reference
implementations attached. They may be consensus critical, or not. The
process for getting a BIP published is fairly loose in that it really
just requires some discussion and relevance to Bitcoin regardless of
whether the proposal is something that would be accepted or used by
others in the ecosystem. The BIP editor is obviously going to filter
out obvious nonesense and that shouldn't be controversial but obvious
when you see it.

You need to separate out the idea of BIPs as is, and implementations
of BIPs in Bitcoin software (like Bitcoin Core).

Take BIP64 for example. It's a proposal that adds a service to nodes
allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
as a project has not implemented it but was instead implemented in XT
and is utilised by Lighthouse. So the BIP specification is there in
the BIPs repository. As far as the bitcoin ecosystem goes, only
Bitcoin XT and lighthouse utilise it so far.

BIP101 is another example, but one of a consensus critical proposal
that would change the Bitcoin protocol (i.e. requires a hard fork). It
was adopted by only the XT project and so far no other software. At
the time of writing miners have chosen not to run implementations of
BIP101.

You can see the BIPs authoring and publishing process is a separate
issue entirely to the implementation and acceptance by the Bitcoin
ecosystem.

For non-consensus critical proposals like BIP64, or maybe one relating
to privacy (how to order transaction output for example), you could
judge acceptance of the proposal by the number of software projects
that implement the proposal, and the number of users it impacts. If a
proposal is utilised by many projects, but not the few projects that
have the majority of users, one could not claim wide acceptance.

For consensus critical proposals like BIP66 (Strict DER encoding) this
BIP was implemented in at least two bitcoin software implementations.
Over 95% of miners adopted the proposal over a 4.5 month period. The
BIP became de facto accepted, and in fact, once 95% lock-in was
achieved, the BIP became Final by rights that the consensus rules for
the Bitcoin network had changed.

In the case of consensus critical proposals like that, you can only
write proposals, implement it in software and hope they are adopted.

Now where does the confusion arise? Well, Bitcoin Core is the de facto
reference implementation by virtue of having the largest technical
contributor base and the widest userbase of any Bitcoin full node
implementation. This is where I believe, the community get stuck in
their assumptions and is so obvious it may have been overlooked.

Consensus rule changes to Bitcoin Core are always documented as BIPs
so the exact details can be picked up by other software implementers
(if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
opcode. The proposal implemented in Bitcoin Core and eventually
merged. Peter also authored BIP65 (required because without it, his
proposal could not be considered for Bitcoin Core).

It is not that BIP65 was somehow "accepted", in fact, as it stands,
BIP65 is still just a draft because while there is a BIP and a
reference implementation in Bitcoin Core, the consensus changes to the
Bitcoin protocol have not been proposed to the community (through a
soft fork), and thus acceptance is still only a possibility (although
acceptance is extremely likely because service providers are literally
chomping at the bit waiting for deployment).

Also I would like to note that it's only an internal rule of Bitcoin
Core that consensus rule changes require a formal BIP. It is not a
requirement laid down from the BIP gods. BIPs simply serve as a way to
communicate ideas and proposals. The community at large will decide if
a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
major influence on this because they have the largest user base. It is
relevant to say the large userbase is not just a historical artefact
by virtue of being the first Bitcoin implementation. Bitcoin Core is
widely trusted by commercial users because of the high developer
count, wide technical expertise and relative security given knowing
that they will be supported with security and maintenance releases.

YOUR PROPOSAL

Getting back to your specific proposal. It seems to focus more on
getting BIPs accepted in the sense of published and missed the wider
picture. As I have detailed, getting published isnt a problem. Anyone
can make a proposal, so long as it's not obviously off topic or
nonsensical, there is no grounds to refuse to publish it.

Any part of your proposal which seems to infer governance of Bitcoin
is misplaced because it's not the place of BIPs. The Bitcoin Core
project is not the BIPs project and their rules are their own. They
are one implementation, and very influential one yes, but, not the one
true implementation to rule them all.

Where I do think the BIP-1 text falls down is with the workflow of
ACCEPTED/REJECTED because it does not really define who is accepting
and rejecting what and misses much of the reality of the process in
the real world. Given the purpose of BIPs is a formal way to
communicate technical proposals to the bitcoin community (i.e.
implementers and protocol consumers) the work flow needs to be
adjusted.

Anyone can submit a proposal and the state of the proposal can be
DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
it's a work in progress, but the proposal is "complete" when the
proposer is happy with the final text. Downstream implementers should
not attempt to write code (in my opinion) until the proposal has been
finalised by the authors. Only the author has the right to say when
their proposal is finished.

The states of Accepted / Rejected are easy for consensus critical
changes, especially once versionbits softforking is enacted and
proposals will have a timeout associated. Certainly for deployed
proposals you could say the proposal is "active" or better still
"pending approval". However "accepted" and "rejected" is difficult for
say privacy standards because how can you gauge or measure it. As I
said earlier, you might have a lot of small projects implementing some
privacy standards, but if the major wallets dont, and thus the
majority of users, how would you gauge it?

Something is a standard only when it becomes a standard by virtue of
having become a standard :)

"Replaced" is an easy state, when another proposal supercedes and
replaces an older one. Again the wording could be better here.
"deprecated" would also be appropriate in some circumstances.

I'm not making a concrete proposal, I'm just highlighting where BIP-1
sort of falls apart because of an incongruence with the workflow
states and what actually happens in real life.

Local to the BIPs project, I do think the BIPs editor, and guidelines
try to filter proposals by raising the bar: i.e. requiring proposal to
be polished through peer review before they are formally published as
draft BIPs. Though this process an author would a) get most of his
details right first time, and b) have some relative confidence his/her
idea was useful and withdraw any obvious bad proposals themselves. An
author may still decide, despite many objections from their peers they
want to proceed with publishing and nothing should stop them providing
it's relevant to the Bitcoin space. Peer review pressure is likely to
act as the best filtering mechanism in this case anyway (no-one would
want to be seen as an ass right?). Personally speaking, I felt quite
nervous proposing my own blocksize ideas. I sought opinions in private
first and had it been widely decried would probably not have pursued
it any further.

So in summary, I think some aspects of BIP-1 could do with polishing
as I have detailed, specially around the "workflow states" but not to
introduce any committees to the process, but where possible to extract
state from the real state of the BIP in the real world. In fact, this
is my direct argument against any forms of committee, in that the
state of a BIP is determined by factors outside of any particular
individual's or groups' purview.

On Fri, Sep 4, 2015 at 9:13 PM, Andy Chase <theandychase@gmail.com> wrote:
> Thanks for your thoughts.
>
> My proposal isn't perfect for sure. There's likely much better ways to do
> it. But to be clear what I'm trying to solve is basically this:
>
> 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.
>
> ---
>
> My motivation for writing this proposal is stated right at the start:
>> "The current process for accepting a BIP is not clearly defined. While
>> BIP-0001 defines the process for writing and submitting a Bitcoin
>> Improvement Proposal to the community it does not specify the precise method
>> for which BIPs are considered accepted or rejected."
>
> BIPs are considered "accepted" right now based on an undefined system, quite
> honestly. Btc Drak: What's the system for accepting a BIP? Words like
> "consensus" come up but they aren't defined. My goal is to define a system
> that makes finding "consensus" (I like the word "acceptance" better) in a
> clear and fair way.
>
> I.e. what's broken?
>
> * Being sure that a proposal is widely accepted or rejected
> * Preventing deadlock (i.e. one person's weak objections preventing
> acceptance)
> * Receiving feedback from important segments like user groups,
> merchants/exchanges, etc. in a systematic and clear way instead of going and
> forth or having "oracles" on technical advisory boards.
>
>> Yes the process is loose, but is it broken?
>
> Yes/No. Work gets done with the current process. Work can get done with this
> process. The goal is for this process is to be safer/clearer/better defined
> way.
>
>> There have been a flood of
>> BIPs added recently with zero bureaucracy or friction.
>
> As we move forward, we want to balance the powers in such a way that we may
> want to pause a bit before we accept each proposal. 2 weeks for comments + 2
> weeks for opinions will slow things down, but it shouldn't stall meaningful
> work. I used 4 weeks for the process with the understanding that most
> proposals are clear and easily acceptable. Controversial proposals will
> likely need more time and thus will likely have be submitted at least twice
> to discover a clear response.
>
> "Accepting" a BIP means just that: It's accepted. What's acceptance mean?
> This proposal provides an answer.
>
> Client implementations, users, miners, and merchants can feel safe
> implementing and using a feature that has clear acceptance. This process
> isn't meant to force anything on client implementors, users, miners, or
> merchants.
>
> On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak <btcdrak@gmail.com> wrote:
>>
>> I'm rather perplexed about this proposal. What exactly is wrong with
>> the existing BIPs process? I mean, it seems to me anyone can publish a
>> BIP pretty easily in the BIPs repository. There doesnt seems to be any
>> real barrier to entry whatsoever. I know there have been all manner of
>> aspersions, but having just written two BIPs there was no friction at
>> all.
>>
>> Whether the ecosystem adopts a BIP is another question of course, but
>> that's out of scope of the BIPs project anyhow. Take BIP101
>> controversial as it gets, but it's there. Whether Bitcoin implementers
>> implement it is another kettle of fish and a matter for each project
>> to decide. It's absolutely NOT the realm of the BIPs project itself.
>> Bitcoin Core does not make any consensus critical changes with a BIP.
>> Where one seeks to establish certain standards, say for privacy, a BIP
>> would be appropriate so the ecosystem can harmonise methodology across
>> the board.
>>
>> The status of a BIP is not really determined by anyone, it's by
>> adoption - that's where consensus happens. There's a little legroom
>> around this but I'm not entirely sure what you are trying to solve.
>> Yes the process is loose, but is it broken? There have been a flood of
>> BIPs added recently with zero bureaucracy or friction.
>>
>> BIP0001 is the BIP that defines the BIP process. Interestingly enough
>> the only BIP that might be controversial is in fact a BIP to change
>> the way BIPs are handled!
>>
>> So I'd really prefer to start this conversation with a breakdown of
>> what you think is broken first before tackling what may or may not
>> need fixing. I would be very cautious bringing "administrative"
>> burdens to the process or evicting common sense from the proceedings.
>> Much of the debates around consensus building seem to negate the
>> importance of common sense and the simple fact that "it's obvious when
>> you see it".
>>
>> I'm sure there can be improvements, but for me personally, I need to
>> see what is broken before I can make any judgement on a potential way
>> forward, and if it's not broken, we should leave it alone.
>>
>>
>> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > As posted:
>> >
>> > **Enforcement/Organization** I agree with your comments. I don't believe
>> > in
>> > setting up an organization to manage this process (would be too much
>> > power
>> > and not really needed because the internet is pretty good at information
>> > sharing). Therefore, I designed it around the assumption that
>> > participation
>> > is voluntary. This means that it's hard to enforce rules like forcing
>> > groups
>> > to see the other side. Groupthink/Echo chambers is real and is bad but
>> > it's
>> > hard to change human nature.
>> >
>> > In regards to enforcement, I believe that the best approach would be to
>> > motivate committees to produce the best opinion they can (and also proof
>> > of
>> > stake, another weak point in this proposal), as the better they can do
>> > this
>> > the more likely the community will accept their opinion as valid and
>> > important.
>> >
>> > Indeed, I believe that without an organization managing the process,
>> > it's up
>> > to each individual reader of each BIP/Opinions set to make the decision
>> > on
>> > whether or not there is clear and true community acceptance.
>> >
>> > ----
>> >
>> > **Committee versus another approach**
>> >
>> > Pros of using Committees:
>> >
>> > * Committees are used today in many fields with a range of success. Lots
>> > of
>> > previous work to work off of here, history is established.
>> > * Many segments already have committee-like structures (Merchants
>> > produce
>> > shared signed documents, miners often represent themselves, User groups
>> > have
>> > representatives like voting on subreddit moderators, Core Devs have Core
>> > Devs)
>> > * Committees can filter a range of opinions down to a yes/no
>> > * Committees have real people that can be talked to, contacted, etc.
>> > * Much easier to proof stake in a range (People generally accept the
>> > Bitcoin
>> > Core has 70-90% of the market share) vs someone trying to proof they
>> > make up
>> > (.000001% of the Bitcoin user-base)
>> > * Committees have some stability, encourages experience and expertise
>> > (Committee members can be knowledgeable in their area and adequately
>> > understand BIPs)
>> >
>> > Cons:
>> >
>> > * Fear of committees working in the dark, censoring opinions (i.e. "Dark
>> > smokey room of fat cats") (Possible solution: make committee power fluid
>> > i.e. easily abandon-able: miners can change pools, users can change
>> > client
>> > forks, change merchants, users can re-group, encourage transparency)
>> > * More centralized, centralization of power (generally bad) (Possible
>> > solution: encourage smaller committees)
>> > * Centralization pressure (groups may seek to consolidate to gain power)
>> > (Possible solution: Segmentation)
>> > * Encourages groupthink, political maneuvers, turns good people into
>> > politicians, mud-tossing
>> >
>> > **Another possible approach: micro votes**
>> >
>> > Pros:
>> >
>> > * Each user can represent themselves, no censorship
>> > * People feel more involved and empowered
>> >
>> > Cons:
>> >
>> > * How to prove and prevent manipulation?
>> > * Only motivated people will contribute. Motivated people may be
>> > motivated
>> > for bad reasons.
>> >
>> >
>> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail.com> wrote:
>> >>
>> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> > I wrote the BIP mostly to stir the pot on ideas of governance
>> >>
>> >> Some quick comments:
>> >>
>> >> I have some objects that I am not ready to put into words, but I do
>> >> think there are easily some major objections to committee design. If I
>> >> vanish and never respond with my objections, perhaps there's an IETF
>> >> RFC about this already....
>> >>
>> >> Something that may mitigate my possible objections would be some
>> >> mandatory requirement about ecosystem echo-chambers making many
>> >> attempts and efforts at steelman representations of alternative
>> >> viewpoints. Understanding objections at a fundamental level, enough to
>> >> make strong steelman statements, is very important to ensure that the
>> >> competing opinions are not censored from consideration. Pathological
>> >> integration and internalization of these steelman arguments can be
>> >> very useful, even if the process looks unusual.
>> >>
>> >> Your process does not have to replace any particular BIP process
>> >> as-is, but rather could be an alternative that proceeds on its own
>> >> perhaps indefinitely without replacement. I don't think too many BIP
>> >> processes are necessarily incompatible except by namespace collision.
>> >>
>> >>
>> >> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
>> >>
>> >> - Bryan
>> >> http://heybryan.org/
>> >> 1 512 203 0507
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>