On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen@mail.bihthai.net> wrote:

Mike Hearn, you should cease your activity of a unilateral hard-fork
immediately. You are doing untold damage by breaking FOSS governance
protocol requiring methodical collaborative work and due process of
change implementation by consensus.

The main principle of open source software is that anyone can fork the code if they wish. They don't do it very often, but they can.

This means that if a project dies, someone can take it over. If some of the devs want to take things in a different direction, they can. Users can decide which version they prefer.

The software itself is what is valuable.

In the case of bitcoin, the blockchain is also (very) valuable. Simply splitting into two projects is not possible for bitcoin.

Otherwise, the discussion would have ended already, those who want a larger block would simply create a fork of the software and create an alt chain.

The fundamental problem is that there is no clear way to make this decision once and for all.

An agreed set of rules for a hard fork would be a nice thing to have, but it is hard to have rules about how to change fundamental rules.

I think using the soft fork rules (maybe with a higher threshold than 95%) plus a delay is a reasonable compromise on hard fork rules.

Even then, it would be nice to include users of the software too. Peter Todd's suggestion of encoding a vote in transactions is a step in that direction (YES transactions in YES blocks and NO transactions in NO blocks).

Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.

Nobody owns it, so there is no court of final appeal.

If miners vote >95% for the fork, users could still refuse to accept the change.

Maybe the sequence could be

version 3 blocks means no opinion

version 4 blocks means NO to fork

version 5 blocks means YES to fork & YES transactions

version 6 blocks means YES to fork & NO transactions

Transaction matching rule:

version 1, 2, 3 transactions means no opinion (can be in any block)

version 4 transactions means YES to fork (cannot be in version 6 blocks)

version 5 transactions means NO to fork (cannot be in version 5 blocks)

Rules

0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching rule activates for version 5 & 6 blocks

1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4 blocks are rejected

2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6 blocks are rejected

3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the last 1000 are version 5 or 6, then the fork is accepted

4) 25,000 blocks after 3 is accepted, hard fork actually takes effect

Once miner acceptance is achieved, then only version 5 and 6 blocks are allowed. The split between version 5 and 6 blocks should be roughly in proportion to the number of transactions of each kind produced.

75% of miners can kill the fork by producing version 4 blocks, but 95% is needed for acceptance. Even then, transaction volume needs to support the fork. I think 75% is reasonable here. (95% of miners and 75% of merchants/users is a pretty strong majority).

You may accuse the community for being antagonistic to you, and
therefore uncooperative, but it is plain to see that your bullheaded
manner eventually generates antagonism wherever you go. Taking Bitcoin
away from this community, in anger, won't solve the problem and will
be like killing the goose that lays the golden eggs.

They are still suggesting some kind of fork threshold process (or at least that is what is being suggested)

If their system requires 95% miner approval, they aren't taking unilateral action. Miners are though if they vote in favour.