Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0489AAC2 for ; Wed, 1 Jul 2015 08:54:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE21C12C for ; Wed, 1 Jul 2015 08:54:14 +0000 (UTC) Received: by wguu7 with SMTP id u7so30544051wgu.3 for ; Wed, 01 Jul 2015 01:54:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9XlkW0IkUsGwqeTCkT9xFfbNBvtsLL1GpglGCiRLfOA=; b=HT0HgL8OJ2nRghXjPZlNQz5GB3a935pd5XQitCe5GsFr1oaNCIFa46KE80g+pWF5an VteEbPK99alPrYMFVk+xUk0YZFVDiXxl2VQ93duqXRBbpj53mL+9jwoQy0EkxP5ZO4di c7uyF2VxFHY14CDkK/wauyUysBR6uZVDN6l5gCz9UzGahJzdCP4fYmWkP85tNjjIXDcZ qD0YQ71GvNbYEIpv1Yp1act+8+Ux90EuwwmUrbnQmJCT+whg8wDBqUnM7Hq+aCupNs27 MK7vPGHih0ppY9uj1W0fLXzkxevALqxR60U6hryObuowM9NNqF4OFhDcey4tS4G8fkiJ nS+g== X-Gm-Message-State: ALoCoQkIeGI1Uhgnq3KDAGrIU0CML3MSlOn8qDGlOvjaUxI4qIxS/F4iRpPpxGXbqMRcVtis1beu X-Received: by 10.180.228.6 with SMTP id se6mr40605456wic.33.1435740853404; Wed, 01 Jul 2015 01:54:13 -0700 (PDT) Received: from [10.0.254.105] (dslb-088-074-068-040.088.074.pools.vodafone-ip.de. [88.74.68.40]) by mx.google.com with ESMTPSA id ck18sm1786178wjb.47.2015.07.01.01.54.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jul 2015 01:54:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeffrey Paul X-Mailer: iPhone Mail (12H143) In-Reply-To: <20150701084512.5924041A40@smtp.hushmail.com> Date: Wed, 1 Jul 2015 10:54:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E6FD4C9-7586-4756-8456-218B9E44B559@eeqj.com> References: <20150701084512.5924041A40@smtp.hushmail.com> To: NxtChg X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE 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] Bitcoin governance 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: Wed, 01 Jul 2015 08:54:16 -0000 If people attempt to govern Bitcoin, Bitcoin falls apart. That's why there is no voting and there are no unnecessary hard forks; Bitco= in operates on consensus. Engineering and research along these lines is folly, as any attempt to impos= e such concepts as "voting" will rightfully find itself with nothing to gove= rn. It is a common misconception that the core devs govern Bitcoin; indeed they a= re the core devs only because they do not try to govern. I urge you to revie= w the history of the term "unix" for an instructive example of what happens i= n systems that do not depend on consensus.=20 And now back to regularly scheduled development, I hope. Best, -jp PS: A personal request to the list: could we please limit ourselves to posti= ng about the research and development of Bitcoin Core? Many of us must stay c= ontinually abreast of all progress on Bitcoin Core by reading all of -dev da= ily and subjecting everyone's email inboxes to hundreds of pet theories abou= t governance and block size opinions without patches or simulations is simpl= y abusing the list membership to soapbox. I encourage you to make blog posts= instead and post them to /r/Bitcoin or suchlike versus taking up attention s= pan on an *engineering* mailing list. --=20 Jeffrey Paul +1 (312) 361-0355 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2 > On 01.07.2015, at 10:45, NxtChg wrote: >=20 > (sorry for the long post, I tried) >=20 > I've been thinking about how we could build an effective Bitcoin governanc= e, but couldn't come up with anything remotely plausible. >=20 > It seems we might go a different way, though, with Core and XT continue co= -existing in parallel, mostly in a compatible state, out of the need that "t= here can be only one". >=20 > Both having the same technical protocol, but different people, structure, p= rocesses and political standing; serving as a kind of two-party system and k= eeping each other in check. >=20 > Their respective power will be determined by the number of Core vs XT node= s running and people/businesses on board. They will have to negotiate any si= gnificant change at the risk of yet another full fork. >=20 > And occasionally the full forks will still happen and the minority will ha= ve to concede and change their protocol to match the winning side. >=20 > Can there be any other way? Can you really control a decentralized system w= ith a centralized governance, like Core Devs or TBF? >=20 > ---- >=20 > In this view, what's happening is a step _towards_ decentralization, not a= way from it. It proves that Bitcoin is indeed a decentralized system and tha= t minority cannot impose its will. >=20 > For the sides to agree now would actually be a bad thing, because that wou= ld mean kicking the governance problem down the road. >=20 > And we _need_ to go through this painful split at least once. The block si= ze issue is perfect: controversial enough to push the split, but not controv= ersial enough so one side couldn't win. >=20 > ---- >=20 > If this is where we're heading then both sides should probably start think= ing of themselves as opposition parties, instead of whatever they think of t= hemselves now. >=20 > People and businesses ultimately decide and they need a way to cast a Yes/= No vote on proposed changes. Hence the two-party system. >=20 > If the split in power is, say, 60/40 and the leading party introduces an u= npopular change, it can quickly lose its advantage. >=20 > We already have the "democratic party" on the left with Gavin and Mike rep= resenting the wish of the majority and the "conservative party" on the right= , who would prefer things to stay the way they are. >=20 > ---- >=20 > Finally, I propose to improve the voting mechanism of Bitcoin to serve thi= s new reality better. >=20 > Using the upcoming fork as an opportunity, we could add something like 8-b= yte votes into blocks: >=20 > * first 4 bytes: fork/party ID, like 'CORE' or 'XT' > * second 4 bytes: proposition number >=20 > (or at least add the ID somewhere so the parties wouldn't have to negotiat= e block version numbers).=20 >=20 >=20 > Miners are in the business of mining coins, so they are good "sensors" of w= here the economic majority will be. >=20 > We will have a representative democracy, with miners serving as 'hubs', co= llecting all the noise and chatter and casting it into a vote. >=20 > This is not perfect, but nothing ever is. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev