[Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mike Hearn]

OK, let's agree to unpack the two things.

The first issue is how are decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it myself. Is it a vote
of people with commit access? Is it a 100% agreement of "core developers"
and if so, who are these people? Is it "whoever reverts the change last"?
Could I write down in a document a precise description of how decisions are
made? No, and that's been a fairly frustrating problem for a long time.

But let's leave it to one side for a moment.

Let's focus on the other issue:   what happens if the Bitcoin Core decision
making process goes wrong?

For the sake of argument let's pretend we're discussing a different change,
let's imagine there is a proposal to change the block format to include a
Widget, where a Widget is some potentially desirable thing. And this change
means a hard fork. Let's put the block size to one side for a second to
avoid getting distracted.

Imagine that 90% of people in Bitcoin want their Widgets, but one of your
committers refuses to accept it.  I am not saying the block size debate has
such proportions but pretend Widgets do.

What is the process for resolving this problem?

Gavin and I say - there is a process, and that process is a hard fork of
the block chain.

What you're saying is - there is no process because a contentious hard fork
must never happen. Such a change is simply impossible.

Now which is a better description of this situation? Is the "it must never
happen end of story" really the cuddly warm democracy that you seem to
suggest? Or is it more like a dictatorship where the opinions of one or two
people can override all the others?

The typical answer I'm seeing to this is that Bitcoin Core's own decision
making process is so fantastic that it never goes wrong, even though
"consensus" is not defined and "technical majority" is not defined and we
have serious long time contributors on this mailing list (such as wallet
developers) disagreeing with this consensus yet our feedback is being
ignored.

You guys *must* accept that your preferred process for resolving disputes
is, itself, in dispute. That leaves the block chain itself as the only
remaining method for bringing this saga to a close.

So this is why we keep disagreeing:

   - If Bitcoin Core has reached a formal decision made by the maintainer
   via whatever mechanism he likes to not accept the block size increase, then
   alright, technical disputes will happen. But ....

   - You should agree that the next step is a fork of both the software and
   the block chain. And you should welcome such a thing because it is the ONLY
   check on your own power. It's the one thing that allows the community to
   reject the decision making process you are using in case it goes wrong.

I keep reading that Bitcoin cannot survive a hard fork. Well, we've
survived an accidental fork that happened without anyone being prepared,
and even with a planned soft fork "never upgrade" isn't really an option
for either miners or businesses, so ultimately node operators must know
about upgrades and make them. Both myself and Gavin think this process can
work out OK.

Do you at least understand where we're coming from here, even if you
disagree? And if you disagree, is it because you think a hard fork to
resolve a dispute can't work technically, or is it some other reason?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/de57a58c/attachment.html>