* [bitcoin-dev] Bitcoin governance
@ 2015-07-01 8:45 NxtChg
2015-07-01 8:54 ` Jeffrey Paul
0 siblings, 1 reply; 4+ messages in thread
From: NxtChg @ 2015-07-01 8:45 UTC (permalink / raw)
To: bitcoin-dev
(sorry for the long post, I tried)
I've been thinking about how we could build an effective Bitcoin governance, but couldn't come up with anything remotely plausible.
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 "there can be only one".
Both having the same technical protocol, but different people, structure, processes and political standing; serving as a kind of two-party system and keeping each other in check.
Their respective power will be determined by the number of Core vs XT nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork.
And occasionally the full forks will still happen and the minority will have to concede and change their protocol to match the winning side.
Can there be any other way? Can you really control a decentralized system with a centralized governance, like Core Devs or TBF?
----
In this view, what's happening is a step _towards_ decentralization, not away from it. It proves that Bitcoin is indeed a decentralized system and that minority cannot impose its will.
For the sides to agree now would actually be a bad thing, because that would mean kicking the governance problem down the road.
And we _need_ to go through this painful split at least once. The block size issue is perfect: controversial enough to push the split, but not controversial enough so one side couldn't win.
----
If this is where we're heading then both sides should probably start thinking of themselves as opposition parties, instead of whatever they think of themselves now.
People and businesses ultimately decide and they need a way to cast a Yes/No vote on proposed changes. Hence the two-party system.
If the split in power is, say, 60/40 and the leading party introduces an unpopular change, it can quickly lose its advantage.
We already have the "democratic party" on the left with Gavin and Mike representing the wish of the majority and the "conservative party" on the right, who would prefer things to stay the way they are.
----
Finally, I propose to improve the voting mechanism of Bitcoin to serve this new reality better.
Using the upcoming fork as an opportunity, we could add something like 8-byte votes into blocks:
* first 4 bytes: fork/party ID, like 'CORE' or 'XT'
* second 4 bytes: proposition number
(or at least add the ID somewhere so the parties wouldn't have to negotiate block version numbers).
Miners are in the business of mining coins, so they are good "sensors" of where the economic majority will be.
We will have a representative democracy, with miners serving as 'hubs', collecting all the noise and chatter and casting it into a vote.
This is not perfect, but nothing ever is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Bitcoin governance
2015-07-01 8:45 [bitcoin-dev] Bitcoin governance NxtChg
@ 2015-07-01 8:54 ` Jeffrey Paul
2015-07-01 12:20 ` Milly Bitcoin
2015-07-01 17:28 ` Justus Ranvier
0 siblings, 2 replies; 4+ messages in thread
From: Jeffrey Paul @ 2015-07-01 8:54 UTC (permalink / raw)
To: NxtChg; +Cc: bitcoin-dev
If people attempt to govern Bitcoin, Bitcoin falls apart.
That's why there is no voting and there are no unnecessary hard forks; Bitcoin operates on consensus.
Engineering and research along these lines is folly, as any attempt to impose such concepts as "voting" will rightfully find itself with nothing to govern.
It is a common misconception that the core devs govern Bitcoin; indeed they are the core devs only because they do not try to govern. I urge you to review the history of the term "unix" for an instructive example of what happens in systems that do not depend on consensus.
And now back to regularly scheduled development, I hope.
Best,
-jp
PS: A personal request to the list: could we please limit ourselves to posting about the research and development of Bitcoin Core? Many of us must stay continually abreast of all progress on Bitcoin Core by reading all of -dev daily and subjecting everyone's email inboxes to hundreds of pet theories about governance and block size opinions without patches or simulations is simply 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 span on an *engineering* mailing list.
--
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:
>
> (sorry for the long post, I tried)
>
> I've been thinking about how we could build an effective Bitcoin governance, but couldn't come up with anything remotely plausible.
>
> 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 "there can be only one".
>
> Both having the same technical protocol, but different people, structure, processes and political standing; serving as a kind of two-party system and keeping each other in check.
>
> Their respective power will be determined by the number of Core vs XT nodes running and people/businesses on board. They will have to negotiate any significant change at the risk of yet another full fork.
>
> And occasionally the full forks will still happen and the minority will have to concede and change their protocol to match the winning side.
>
> Can there be any other way? Can you really control a decentralized system with a centralized governance, like Core Devs or TBF?
>
> ----
>
> In this view, what's happening is a step _towards_ decentralization, not away from it. It proves that Bitcoin is indeed a decentralized system and that minority cannot impose its will.
>
> For the sides to agree now would actually be a bad thing, because that would mean kicking the governance problem down the road.
>
> And we _need_ to go through this painful split at least once. The block size issue is perfect: controversial enough to push the split, but not controversial enough so one side couldn't win.
>
> ----
>
> If this is where we're heading then both sides should probably start thinking of themselves as opposition parties, instead of whatever they think of themselves now.
>
> People and businesses ultimately decide and they need a way to cast a Yes/No vote on proposed changes. Hence the two-party system.
>
> If the split in power is, say, 60/40 and the leading party introduces an unpopular change, it can quickly lose its advantage.
>
> We already have the "democratic party" on the left with Gavin and Mike representing the wish of the majority and the "conservative party" on the right, who would prefer things to stay the way they are.
>
> ----
>
> Finally, I propose to improve the voting mechanism of Bitcoin to serve this new reality better.
>
> Using the upcoming fork as an opportunity, we could add something like 8-byte votes into blocks:
>
> * first 4 bytes: fork/party ID, like 'CORE' or 'XT'
> * second 4 bytes: proposition number
>
> (or at least add the ID somewhere so the parties wouldn't have to negotiate block version numbers).
>
>
> Miners are in the business of mining coins, so they are good "sensors" of where the economic majority will be.
>
> We will have a representative democracy, with miners serving as 'hubs', collecting all the noise and chatter and casting it into a vote.
>
> This is not perfect, but nothing ever is.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Bitcoin governance
2015-07-01 8:54 ` Jeffrey Paul
@ 2015-07-01 12:20 ` Milly Bitcoin
2015-07-01 17:28 ` Justus Ranvier
1 sibling, 0 replies; 4+ messages in thread
From: Milly Bitcoin @ 2015-07-01 12:20 UTC (permalink / raw)
To: bitcoin-dev
>It is a common misconception that the core devs govern Bitcoin;
They set standards rather than govern. It is an important standard, but
it is a voluntary standard. How important that standard in terms of
defining the consensus rules is subject to speculation and the amount of
influence depends on the specific circumstances. Maybe some wording can
be changed to reflect that it is a voluntary standard.
Russ
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Bitcoin governance
2015-07-01 8:54 ` Jeffrey Paul
2015-07-01 12:20 ` Milly Bitcoin
@ 2015-07-01 17:28 ` Justus Ranvier
1 sibling, 0 replies; 4+ messages in thread
From: Justus Ranvier @ 2015-07-01 17:28 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 394 bytes --]
On 07/01/2015 03:54 AM, Jeffrey Paul wrote:
> could we please limit ourselves to posting about the research and development of Bitcoin Core?
If that's the purpose of this list, then it is misleadingly named.
If development of Bitcoin Core, the application, is to be considered
independent from development of Bitcoin, the protocol, then Bitcoin Core
development needs its own list.
[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-07-01 17:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-01 8:45 [bitcoin-dev] Bitcoin governance NxtChg
2015-07-01 8:54 ` Jeffrey Paul
2015-07-01 12:20 ` Milly Bitcoin
2015-07-01 17:28 ` Justus Ranvier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox