From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 06DB1E1C for ; Fri, 4 Sep 2015 19:21:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCABB184 for ; Fri, 4 Sep 2015 19:21:19 +0000 (UTC) Received: by wicge5 with SMTP id ge5so27019264wic.0 for ; Fri, 04 Sep 2015 12:21:18 -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=+5y7RZWahRCXvIKktER6USiw3Abd9Cldji7xmoPyT2w=; b=jigLEASWNI+pl6XQMJ3WB3R6Z68e0f2kcrcMQSlE8SwpXy7htNfCQZGcqqpD/n564Q szY/uiA7/wHB/ZdEokuL/H+XmObo4Srfan91lv0/T0EPnjnOfFa3MWhiBeW0Y42kFn0I 7OrDei5BJDNXRTC2XQN6j0ZACeUF0/tuqy1khQyQup6ORvJXGSp1gYOvcOHjgtjb3buT 87RNYmQ2iZ9Vk3jEO3JIKvXoPPIwuLzYfRgWjiE3fRjP5aahhMNl63FLctv0V/SQTDXn YgPRAh/EL9nZeAzR48Zq+2R6yHxQdCosPTNw09gPiEu0RxVhIOXnLAVXdgVed0j+UUTZ ourw== X-Received: by 10.180.37.164 with SMTP id z4mr10140504wij.28.1441394478605; Fri, 04 Sep 2015 12:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.16 with HTTP; Fri, 4 Sep 2015 12:20:58 -0700 (PDT) In-Reply-To: References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> From: Btc Drak Date: Fri, 4 Sep 2015 20:20:58 +0100 Message-ID: To: Andy Chase Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_20,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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 19:21:21 -0000 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 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 wrote: >> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev >> 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 >