Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jeffrey Paul <jp@eeqj.com>
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>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin governance
Precedence: list

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