path: root/d7/1e5848a145707e1095e8f124ff2545119451f0

Return-Path: <jp@eeqj.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0489AAC2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  1 Jul 2015 08:54:14 +0000 (UTC)
Received: by wguu7 with SMTP id u7so30544051wgu.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <jp@eeqj.com>
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 <nxtchg@hush.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <nxtchg@hush.com> 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